Skip to content
  • Kiyoshi Ueda's avatar
    block: add request update interface · 32fab448
    Kiyoshi Ueda authored
    This patch adds blk_update_request(), which updates struct request
    with completing its data part, but doesn't complete the struct
    request itself.
    Though it looks like end_that_request_first() of older kernels,
    blk_update_request() should be used only by request stacking drivers.
    
    Request-based dm will use it in bio->bi_end_io callback to update
    the original request when a data part of a cloned request completes.
    Followings are additional background information of why request-based
    dm needs this interface.
    
      - Request stacking drivers can't use blk_end_request() directly from
        the lower driver's completion context (bio->bi_end_io or rq->end_io),
        because some device drivers (e.g. ide) may try to complete
        their request with queue lock held, and it may cause deadlock.
        See below for detailed description of possible deadlock:
        <http://marc.info/?l=linux-kernel&m=120311479108569&w=2
    
    >
    
      - To solve that, request-based dm offloads the completion of
        cloned struct request to softirq context (i.e. using
        blk_complete_request() from rq->end_io).
    
      - Though it is possible to use the same solution from bio->bi_end_io,
        it will delay the notification of bio completion to the original
        submitter.  Also, it will cause inefficient partial completion,
        because the lower driver can't perform the cloned request anymore
        and request-based dm needs to requeue and redispatch it to
        the lower driver again later.  That's not good.
    
      - So request-based dm needs blk_update_request() to perform the bio
        completion in the lower driver's completion context, which is more
        efficient.
    
    Signed-off-by: default avatarKiyoshi Ueda <k-ueda@ct.jp.nec.com>
    Signed-off-by: default avatarJun'ichi Nomura <j-nomura@ce.jp.nec.com>
    Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
    32fab448