[PATCH 0/11] Take #2: Resurrect sdev during scanning

[Hannes Reinecke <hare@suse.de>]

Hi James,

this is a rework of my earlier patchset to address the outstanding 'sdev
oops during scanning' issue. Problem is that any sdev in state
'SDEV_DEL' is still visible to the host until the refcount drops to
zero. When a scan occurs during this time we access a half-initialized
sdev and all hell breaks loose.

To address this issue this patchset expands the sdev state-machine to
allow a transition from SDEV_DEL back to SDEV_RUNNING. This is
implemented in the function scsi_resurrect_device(). So during scan we
only have to make sure to call scsi_resurrect_device() on all sdevs as
this will guarantee us that the sdev is operational during scanning.

In order to do so I reworked the sdev allocation and removal so that
we're more aligned with the sdev state machine and the driver core's
device_initialize / device_add logic.

Additionally I have expanded the state machine even more by introducing
a SDEV_NEW state, which will transition into SDEV_CREATED once
slave_alloc() is run.  This will allow us to detect from within the
->release function whether slave_destroy() should be called.
With this we don't have to modify any LLDD, thus addressing the issue
hch had with the earlier patchset.

Comments etc. welcome.

Otherwise, please apply.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html