michaelc@xxxxxxxxxxx wrote on Tue, 11 Mar 2008 00:36 -0500:
> Actually one of the problems looks a little different than some of the
> problems hit with sg and are caused because we remove the bsg device too
> soon. I think we want to wait until all the references from the
> commands/requests are released. The attached patch (untested) moves the bsg
> unreg call to the scsi device release fn.
> Delay bsg unregistration, because we want to wait until all the request/cmds
> have released their reference.
>
> Signed-off-by: Mike Christie <michaelc@xxxxxxxxxxx>
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index ed83cdb..b9b09a7 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -294,6 +294,7 @@ static void scsi_device_dev_release_usercontext(struct work_struct *work)
> }
>
> if (sdev->request_queue) {
> + bsg_unregister_queue(sdev->request_queue);
> sdev->request_queue->queuedata = NULL;
> /* user context needed to free queue */
> scsi_free_queue(sdev->request_queue);
> @@ -857,7 +858,6 @@ void __scsi_remove_device(struct scsi_device *sdev)
> if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0)
> return;
>
> - bsg_unregister_queue(sdev->request_queue);
> class_device_unregister(&sdev->sdev_classdev);
> transport_remove_device(dev);
> device_del(dev);
This definitely avoids the hang in [BUG 3/3]. Instead I get the
useful console message:
scsi 4:0:0:1: rejecting I/O to dead device
My tested-by for that. But it leaves a bit of a mess in sysfs.
Apparently udev did not get the message that these devs went away.
ib30$ ll /sys/class/scsi_device/
total 0
drwxr-xr-x 3 root root 0 Mar 14 20:04 ./
drwxr-xr-x 28 root root 0 Mar 14 20:02 ../
drwxr-xr-x 2 root root 0 Mar 14 20:02 2:0:0:0/
ib30$ ll /dev/bsg/
total 0
drwxr-xr-x 2 root root 100 Mar 14 20:03 ./
drwxr-xr-x 12 root root 3020 Mar 14 20:04 ../
crw-rw-rw- 1 root root 254, 0 Mar 14 20:02 2:0:0:0
crw-rw-rw- 1 root root 254, 1 Mar 14 20:03 4:0:0:0
crw-rw-rw- 1 root root 254, 2 Mar 14 20:03 4:0:0:1
I do have a special udev rule to explain why the devs look like
this:
ACTION=="add", SUBSYSTEM=="bsg", NAME="bsg/%k", MODE="0666", OPTIONS="last_rule"
but that doesn't explain why they're still in /dev.
-- Pete
--
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
