On 03/21/12 03:37, Dan Williams wrote: > On Tue, Mar 20, 2012 at 2:01 PM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >> On Tue, Mar 20, 2012 at 1:06 PM, Bart Van Assche <bvanassche@xxxxxxx> wrote: >> [..] >>> - Fix a null pointer dereference triggered by sd during device removal. >> Hi Bart, >> >> Do you have a log of the backtrace in this case? I'm going to put >> this patch into our libsas/isci test environment. > We beat on this patch pretty severely in our environment and appeared > to only trigger a hung_task timeout when our driver / libata took too > long to recovery for a 15 device unplug. Thanks for testing - that's appreciated. The null pointer dereference triggered during device removal was originally reported by Jun'ichi Nomura. A call stack can be found here: http://www.spinics.net/lists/linux-scsi/msg56254.html. Regarding invoking blk_cleanup_queue() on a stopped queue: some code I was testing could trigger this. But as far as I can see both the fc and iSCSI transport layer code take care to unblock a queue before destroying it, so these transports are not affected. There are other (non-SCSI) block drivers though that can stop and restart the queue. I haven't analyzed all of them. So I'm not sure there is currently any upstream code that invokes blk_cleanup_queue() on a stopped queue. Bart. -- 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
