On Wed, 04 Feb 2009 22:35:23 -0500 Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote: > FUJITA Tomonori wrote: > > This is against scsi-misc. > > > > = > > From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> > > Subject: [PATCH] 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@xxxxxxxxxxxxx> > > Interesting technique. Yeah, I must say that it's hacky. But I'd like to avoid adding something new to the block layer mapping API for only sg. st (and osst) also calls blk_rq_unmap_user in interrupt but they should be fine since the maping API doesn't do data transfer for them (always use BIO_NULL_MAPPED flag). Thanks, -- 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
