[SCSI] sg: avoid blk_put_request/blk_rq_unmap_user in interrupt
authorFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Wed, 4 Feb 2009 02:36:27 +0000 (11:36 +0900)
committerJames Bottomley <James.Bottomley@HansenPartnership.com>
Thu, 12 Mar 2009 17:58:12 +0000 (12:58 -0500)
commitc96952ed7031e7c576ecf90cf95b8ec099d5295a
tree4217498cf82131f6c870b0f92fea7039596fa0e7
parenta3b7aeaba29e3dd995ece05ba50db9e0650c16b6
[SCSI] sg: avoid blk_put_request/blk_rq_unmap_user in interrupt

This fixes the following oops:

http://marc.info/?l=linux-kernel&m=123316111415677&w=2

You can reproduce this bug by interrupting a program before a sg
response completes. This leads to the special sg state (the orphan
state), then sg calls blk_put_request in interrupt (rq->end_io).

The above bug report shows the recursive lock problem because sg calls
blk_put_request in interrupt. We could call __blk_put_request here
instead however we also need to handle blk_rq_unmap_user here, which
can't be called in interrupt too.

In the orphan state, we don't need to care about the data transfer
(the program revoked the command) so adding 'just free the resource'
mode to blk_rq_unmap_user is a possible option.

I prefer to avoid complicating the blk mapping API when possible. I
change the orphan state to call sg_finish_rem_req via
execute_in_process_context. We hold sg_fd->kref so sg_fd doesn't go
away until keventd_wq finishes our work. copy_from_user/to_user fails
so blk_rq_unmap_user just frees the resource without the data
transfer.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
drivers/scsi/sg.c