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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
