block: add rq->complete_io hook for request stacking
This patch adds ->complete_io() hook for request stacking.
Request stacking drivers (such as request-based dm) can set
a callback for completion.
(The hook is not called in blk_end_io(), since request-based dm uses
it for clone completion in the following appendix patches.)
For the stacking to work without deadlock between stacking devices,
both the submission function and the completion function must be
called without the queue lock.
So the stacking is not available for __blk_end_request(), which
is called with the queue lock held.
The patch adds a queue flag (QUEUE_FLAG_STACKABLE) and a check to
make sure that the stacking is not enabled in drivers calling
__blk_end_request().
It means that only scsi mid-layer, cciss and i2o are ready for
the stacking.
I believe current dm-multipath users are using scsi, cciss and dasd.
So at least, dasd needs to be changed not to use __blk_end_request()
for request-based dm-multipath.
Below is the detailed explanation why the stacking is not possible
for drivers using __blk_end_request().
If the completion function is called with the queue lock held,
we have 2 deadlock problems:
a). when the stacking driver completes the hooked request
b). when the stacking driver submits other requests in that
completion context
Suppose we have the following stack:
________________________
| |
| stacking device: DEV#2 |
|________________________|
________________________
| |
| real device: DEV#1 |
|________________________|
For example of a):
1. The device driver takes the queue lock for DEV#1
2. The device driver calls __blk_end_request() for the request
and it is hooked by the stacking driver
3. The stacking driver tries to take the queue lock for DEV#1
to complete the hooked request
=> deadlock happens on the queue lock for DEV#1
For example of b): Assume the a) is worked-around by something
1. The device driver takes the queue lock for DEV#1
2. The device driver calls __blk_end_request() for the request
and it is hooked by the stacking driver
3. The stacking driver completes the hooked request
4. The stacking driver dequeues the next request from DEV#2
to dispatch quickly due to some performance reasons
5. The stacking driver tries to take the queue lock for DEV#1
to submit the next request
=> deadlock happens on the queue lock for DEV#1
To prevent such deadlock problems on the stacking, I'd like to say
that drivers which hold the queue lock when completing request are
not ready for the stacking.
So drivers using __blk_end_request() (and end_[queued|dequeued_]request())
need to be modified in this request stacking design, if we need to
use such devices for the stacking.
To prevent request stacking drivers from using such unstackable
devices, a queue flag, QUEUE_FLAG_STACKABLE, is added.
And device drivers can set it to be used by request stacking drivers.
(scsi patch is included just for an example of the setting.)
To detect wrong use of the flag and the hook, some checks are also
put in __blk_end_request().