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@xxxxxxx +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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
