[SCSI] scsi_transport_sas: move bsg destructor into sas_rphy_remove
authorJoe Lawrence <joe.lawrence@stratus.com>
Thu, 22 May 2014 21:30:54 +0000 (17:30 -0400)
committerJames Bottomley <JBottomley@Parallels.com>
Thu, 22 May 2014 22:54:03 +0000 (15:54 -0700)
commit6aa6caff30f5dcb9e55b03b9710c30b83750cae5
treef2e13cc12af0a3f7810a0bb9d00a36d53a73267d
parent0c8482ac92db5ac15792caf23b7f7df9e4f48ae1
[SCSI] scsi_transport_sas: move bsg destructor into sas_rphy_remove

The recent change in sysfs, bcdde7e221a8750f9b62b6d0bd31b72ea4ad9309
"sysfs: make __sysfs_remove_dir() recursive" revealed an asymmetric
rphy device creation/deletion sequence in scsi_transport_sas:

  modprobe mpt2sas
    sas_rphy_add
      device_add A               rphy->dev
      device_add B               sas_device transport class
      device_add C               sas_end_device transport class
      device_add D               bsg class

  rmmod mpt2sas
    sas_rphy_delete
      sas_rphy_remove
        device_del B
        device_del C
        device_del A
          sysfs_remove_group     recursive sysfs dir removal
      sas_rphy_free
        device_del D             warning

  where device A is the parent of B, C, and D.

When sas_rphy_free tries to unregister the bsg request queue (device D
above), the ensuing sysfs cleanup discovers that its sysfs group has
already been removed and emits a warning, "sysfs group... not found for
kobject 'end_device-X:0'".

Since bsg creation is a side effect of sas_rphy_add, move its
complementary removal call into sas_rphy_remove. This imposes the
following tear-down order for the devices above: D, B, C, A.

Note the sas_device and sas_end_device transport class devices (B and C
above) are created and destroyed both via the list match traversal in
attribute_container_device_trigger, so the order in which they are
handled is fixed. This is fine as long as they are deleted before their
parent device.

Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
drivers/scsi/scsi_transport_sas.c