James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote:
> static void scsi_target_reap_usercontext(void *data)
> @@ -391,21 +400,13 @@
> struct Scsi_Host *shost = dev_to_shost(starget->dev.parent);
> unsigned long flags;
>
> + transport_remove_device(&starget->dev);
> + device_del(&starget->dev);
> + transport_destroy_device(&starget->dev);
> spin_lock_irqsave(shost->host_lock, flags);
> -
> - if (--starget->reap_ref == 0 && list_empty(&starget->devices)) {
> - list_del_init(&starget->siblings);
> - spin_unlock_irqrestore(shost->host_lock, flags);
> - transport_remove_device(&starget->dev);
> - device_del(&starget->dev);
> - transport_destroy_device(&starget->dev);
> - put_device(&starget->dev);
> - return;
> -
> - }
> + list_del_init(&starget->siblings);
> spin_unlock_irqrestore(shost->host_lock, flags);
> -
> - return;
> + put_device(&starget->dev);
> }
>
> /**
The patch was tried on the aic7xxx ahc_linux_target_alloc issue I
previously mentioned and it did not change the result of a BUG_ON.
Is there some reason we cannot do the list_del_init(&starget->siblings) in
scsi_target_dev_release post calling target_destroy? It would appear with
the check for STARGET_DEL that being on the list longer should not be a
problem.
For the sdev we call the slave_destroy in __scsi_remove_device and then pull
it off the list in the release.
-andmike
--
Michael Anderson
andmike@xxxxxxxxxx
-
: 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
