On Wed, 2011-05-25 at 16:42 -0400, Parag Warudkar wrote: > Yeah - that makes sense. By that logic, looks like we can only disallow > for SDEV_DEL (if we decide to do that check here). I don't think this is the root cause. I think q is non-NULL but has already been released, so we're just getting a NULL deref on the actual list head. Does this fix it? It adds the refcounting at approximately the correct places. Of course, we'll now be trying elevator operations on an extant queue but one whose elevator functions have been destroyed, so there are probably additional state guards to place. James --- diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 58584dc..44e8ca3 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -297,7 +297,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget, kfree(sdev); goto out; } - + blk_get_queue(sdev->request_queue); sdev->request_queue->queuedata = sdev; scsi_adjust_queue_depth(sdev, 0, sdev->host->cmd_per_lun); diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c index e639125..e0bd3f7 100644 --- a/drivers/scsi/scsi_sysfs.c +++ b/drivers/scsi/scsi_sysfs.c @@ -322,6 +322,7 @@ static void scsi_device_dev_release_usercontext(struct work_struct *work) kfree(evt); } + blk_put_queue(sdev->request_queue); /* NULL queue means the device can't be used */ sdev->request_queue = NULL; -- 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
