On 06/05/2012 07:10 PM, Bart Van Assche wrote:
> Some request_queue.end_io implementations can be called safely
> without the queue lock held while several other implementations
> assume that the queue lock is held. So let's play it safe and
> make sure that the queue lock is held around end_io invocations.
> Found this through source code review.
>
> Signed-off-by: Bart Van Assche <bvanassche@xxxxxxx>
> Cc: Jens Axboe <axboe@xxxxxxxxx>
> Cc: Tejun Heo <tj@xxxxxxxxxx>
> Cc: <stable@xxxxxxxxxx>
> ---
> block/blk-exec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/block/blk-exec.c b/block/blk-exec.c
> index fb2cbd5..6724fab 100644
> --- a/block/blk-exec.c
> +++ b/block/blk-exec.c
> @@ -54,10 +54,10 @@ void blk_execute_rq_nowait(struct request_queue *q, struct gendisk *bd_disk,
> spin_lock_irq(q->queue_lock);
>
> if (unlikely(blk_queue_dead(q))) {
> - spin_unlock_irq(q->queue_lock);
> rq->errors = -ENXIO;
> if (rq->end_io)
> rq->end_io(rq, rq->errors);
> + spin_unlock_irq(q->queue_lock);
> return;
> }
I'm assuming you checked any in-kernel users of rq->end_io to ensure
that it is fine? If so, patch looks fine to me. And I agree, it's not
stable material.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
