Re: [PATCH] fix scsi process problems and clean up the target reap issues

[Mike Anderson <andmike@us.ibm.com>]

James Bottomley <James.Bottomley@SteelEye.com> 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@us.ibm.com