On Sun, 3 Jul 2011, Alan Stern wrote:

> > Your explanation completely contradicts what James wrote earlier.
> 
> Yes, it does.  I'm claiming that James was on a wrong track or looking
> in the wrong direction.

To amplify: James wrote:

> Right, that wouldn't work.  The sdev in question comes from
> request_queue->queuedata.  That only goes to null when the last
> reference to the sdev has been released.  So the root cause is something
> in sd holding a reference to sdev without actually getting an additional
> refcount.

The third sentence is clearly wrong, because queuedata is set to NULL
when sdev is removed from visibility, not when the last reference to it
has been released, i.e., in __scsi_remove_device() rather than
scsi_device_dev_release_usercontext().

Maybe this means the assignment to queuedata should be moved.  I don't 
know; unlike James, I'm not an expert on the details of the SCSI stack.

Alan Stern