Take #2: Resurrect sdev during scanning
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest11 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/11 | Add scsi_destroy_device()drivers/ include/ | +7 | 0 replies | |
| 2/11 | Improve error messages in scsi_sysfs_add_sdev()drivers/ | +4 | 0 replies | |
| 3/11 | Remove stale put_device() from scsi_sysfs_add_sdev()drivers/ | +0 | 0 replies | |
| 4/11 | Implement SDEV_NEW statedrivers/ drivers/ drivers/ +1 more | +24 | 0 replies | |
| 5/11 | Free sdev class device from release functiondrivers/ drivers/ | +24 | 0 replies | |
| 6/11 | Rename __scsi_remove_device() into scsi_sysfs_remove_sdev()drivers/ drivers/ drivers/ | +8 | 0 replies | |
| 7/11 | Implement scsi_configure_device()drivers/ | +49 | 0 replies | |
| 8/11 | Remove obsolete scsi_destroy_sdev() functiondrivers/ | +0 | 0 replies | |
| 9/11 | Implement scsi_resurrect_device()drivers/ drivers/ drivers/ | +58 | 0 replies | |
| 10/11 | Fixup scsi_sysfs_add_sdev()drivers/ | +10 | 0 replies | |
| 11/11 | State machine cleanupdrivers/ | +9 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/11] Take #2: Resurrect sdev during scanning
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
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html