Re: [SCSI] fix scsi_reap_target() device_del from atomic context

[James Bottomley <James.Bottomley@SteelEye.com>]

On Fri, 2005-12-23 at 23:43 +0300, Sergey Vlasov wrote:
> So if that GFP_ATOMIC allocation ever fails, the target is leaked
> forever - does not look nice.

Yes, but it will print a warning.

> Does anything depend on starget->siblings being empty after we had
> removed it from the shost->__targets list it was on?  Seems that all
> other uses of this field are:
>
> drivers/scsi/scsi_scan.c:313:   list_for_each_entry(starget, &shost->__targets, siblings) {
> drivers/scsi/scsi_scan.c:365:   INIT_LIST_HEAD(&starget->siblings);
> drivers/scsi/scsi_scan.c:373:   list_add_tail(&starget->siblings, &shost->__targets);
> 
> So probably we can reuse this field and do deferred reaping without any
> memory allocation at all.  The following patch should be applied
> _instead_ of the James' patch, not on top of it (I can make a combined
> patch if it is desired).  The difference with the previous patch is that
> scsi_target_reap() still removes the target from shost->__targets
> immediately - only device_del() and subsequent actions are deferred to a
> workqueue.

No, you can't.

If you do this, the target namespace will potentially be in use in sysfs
after the system thinks the target is gone.  Thus, any reallocation
fails because you can't add a new target with the same name as an
existing one.

James