Re: [BUG] 2.6.39.1 crash in scsi_dispatch_cmd()

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2011-07-06 at 10:20 -0400, Alan Stern wrote:
> On Wed, 6 Jul 2011, Roland Dreier wrote:
> 
> > Alan Stern's patch looks a bit fishy -- the scsi_free_queue() is moved
> > earlier than the
> > 
> > 	/* cause the request function to reject all I/O requests */
> > 	sdev->request_queue->queuedata = NULL;
> > 
> > which seems to leave a small window where the use-after-free can
> > happen, and it's not clear to me why the scsi_free_queue() has to move
> > at all.
> 
> Looks can be deceiving.  Although the scsi_free_queue() is higher up in
> the source file, it actually runs later than this code.  That's because
> __scsi_remove_device() -- this code -- gets called when the device is
> unregistered from the driver core, whereas
> scsi_device_dev_release_usercontext() -- where the scsi_free_queue() is
> moved to -- gets called when the last reference to the device is
> dropped.
> 
> Now, one of the things I'm not sure about (it would nice if James would
> pick up this thread again and comment) is whether queuedata should be
> set to NULL at unregistration time or later on, when the device and the
> queue are about to be freed.

Sorry, higher priority problems at the moment.  Sorry about the
->queuedata cockup, was thinking of sdev->request_queue. Moving the
queue free is wrong ... it recently moved to fix another oops.  Problem
most likely missing block guards on blk_execute_req() ... no check for
QUEUE_DEAD.

Will be back on Thursday.

James