RE: Error 1 & scsi_add_device()

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

On Thu, 2006-08-17 at 10:02 -0400, Salyzyn, Mark wrote:
> None of this leads me to believe there is any kref node corruption,
> but
> code could expect that if a device existed at the nexus and the
> subsystem acquired another reference to the node based on the nexus
> rather than the scsi_device, thus using scsi_device_lookup, that they
> would get an unexpected NULL pointer and choke. I have not inspected
> the
> code for such a path (yet), but feel we have risks in any case that
> need
> to be addressed.
> 
> The aacraid driver should stop calling scsi_remove_device when an
> array
> is deleted ... or ...
> 
> I believe what needs to be added is a check for sdev->sdev_state ==
> SDEV_DEL in __scsi_device_lookup_by_target and __scsi_device_lookup in
> scsi.c:

That would solve some of this... but that's not quite the whole of it,
unfortunately.  The error 1 problem is caused by the external namespace
visibility, which the SDEV_DEL check will prevent (the device only goes
into DEL after the namespace entry has been removed, so its now safe to
repopulate it with a new device).

However, there's a race you probably haven't come across yet where you
do the same thing and get a device in SDEV_CANCEL.  This means currently
visible but dying (i.e. the only state it's going from CANCEL is DEL).

To fix all of this, we probably need better state model checking in
probe_and_add_lun() plus a parameter that says "wait and create a new
device if this one is being removed" ... I suspect we can cannibalise
the rescan parameter for that.

James


The three relevant states in the model are SDEV_CREATED (this means the
device exists b