James Bottomley wrote:
[...]
> --- linux-2.6.orig/drivers/scsi/scsi.c
> +++ linux-2.6/drivers/scsi/scsi.c
> @@ -835,14 +835,14 @@ EXPORT_SYMBOL(scsi_track_queue_full);
> */
> int scsi_device_get(struct scsi_device *sdev)
> {
> - if (sdev->sdev_state == SDEV_DEL || sdev->sdev_state == SDEV_CANCEL)
> + if (sdev->sdev_state == SDEV_DEL)
> return -ENXIO;
> if (!get_device(&sdev->sdev_gendev))
> return -ENXIO;
> - if (!try_module_get(sdev->host->hostt->module)) {
> - put_device(&sdev->sdev_gendev);
> - return -ENXIO;
> - }
> + /* We can fail this if we're doing SCSI operations
> + * from module exit (like cache flush) */
> + try_module_get(sdev->host->hostt->module);
> +
> return 0;
> }
> EXPORT_SYMBOL(scsi_device_get);
> @@ -857,7 +857,10 @@ EXPORT_SYMBOL(scsi_device_get);
> */
> void scsi_device_put(struct scsi_device *sdev)
> {
> - module_put(sdev->host->hostt->module);
> + /* The module refcount will be zero if scsi_device_get()
> + * was called from a module removal routine */
> + if (likely(module_refcount(sdev->host->hostt->module) != 0))
> + module_put(sdev->host->hostt->module);
> put_device(&sdev->sdev_gendev);
> }
> EXPORT_SYMBOL(scsi_device_put);
Somehow the (void)try_module_get(...) looks dangerous to me. Is it
really safe to always ignore failures to get the module? Why would we
want to ignore failures? Couldn't there be border cases where a
module_getter/_putter in a concurrent code path disturbs
scsi_device_get/_put's underlying assumptions?
--
Stefan Richter
-=====-=-==- =--= ----=
http://arcgraph.de/sr/
-
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
