kernel.git/drivers/scsi/ses.c, branch linux-4.16.y

scsi: ses: don't ask for diagnostic pages repeatedly during probe

2017-12-05T03:55:59Z

We are testing if there is a match with the ses device in a loop by calling ses_match_to_enclosure(), which will issue scsi receive diagnostics commands to the ses device for every device on the same host. On one of our boxes with 840 disks, it takes a long time to load the driver: [root@g1b-oss06 ~]# time modprobe ses real 40m48.247s user 0m0.001s sys 0m0.196s With the patch: [root@g1b-oss06 ~]# time modprobe ses real 0m17.915s user 0m0.008s sys 0m0.053s Note that we still need to refresh page 10 when we see a new disk to create the link. Signed-off-by: Li Dongyang Tested-by: Jason Ozolins Signed-off-by: Martin K. Petersen

Merge branch 'fixes' into misc

2017-09-07T19:12:43Z

scsi: ses: Fix racy cleanup of /sys in remove_dev()

2017-08-25T21:35:40Z

Currently we free the resources backing the enclosure device before we call device_unregister(). This is racy: during rmmod of low-level SCSI drivers that hook into enclosure, we end up with a small window of time during which writing to /sys can OOPS. Example trace with mpt3sas: general protection fault: 0000 [#1] SMP KASAN Modules linked in: mpt3sas(-) <...> RIP: [] ses_get_page2_descriptor.isra.6+0x38/0x220 [ses] Call Trace: [] ses_set_fault+0xf4/0x400 [ses] [] set_component_fault+0xa9/0xf0 [enclosure] [] dev_attr_store+0x3c/0x70 [] sysfs_kf_write+0x115/0x180 [] kernfs_fop_write+0x275/0x3a0 [] __vfs_write+0xe0/0x3e0 [] vfs_write+0x13f/0x4a0 [] SyS_write+0x111/0x230 [] entry_SYSCALL_64_fastpath+0x13/0x94 Fortunately the solution is extremely simple: call device_unregister() before we free the resources, and the race no longer exists. The driver core holds a reference over ->remove_dev(), so AFAICT this is safe. Signed-off-by: Calvin Owens Acked-by: Hannes Reinecke Signed-off-by: Martin K. Petersen

scsi: ses: make page2 support optional

2017-08-25T02:28:59Z

Simple subenclosures do not need to support SES page 2, so make it optional. Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen

scsi: ses: Fixup error message 'failed to get diagnostic page 0xffffffea'

2017-08-25T02:28:58Z

The printk was using the result as argument, leading to a slightly confusing log message. Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen

scsi: ses: check return code from ses_recv_diag()

2017-08-25T02:28:58Z

We should be checking the return code from ses_recv_diag() to avoid accessing invalid data. Signed-off-by: Hannes Reinecke Signed-off-by: Martin K. Petersen

scsi: ses: Fix wrong page error

2017-08-08T15:49:52Z

If a SES device returns an error on a requested diagnostic page, we are currently printing an error indicating the wrong page was received. Fix this up to simply return a failure and only check the returned page when the diagnostic page buffer was populated by the device. Signed-off-by: Brian King Signed-off-by: Martin K. Petersen

scsi: ses: don't get power status of SES device slot on probe

2017-04-06T16:48:05Z

The commit 08024885a2a3 ("ses: Add power_status to SES device slot") introduced the 'power_status' attribute to enclosure components and the associated callbacks. There are 2 callbacks available to get the power status of a device: 1) ses_get_power_status() for 'struct enclosure_component_callbacks' 2) get_component_power_status() for the sysfs device attribute (these are available for kernel-space and user-space, respectively.) However, despite both methods being available to get power status on demand, that commit also introduced a call to get power status in ses_enclosure_data_process(). This dramatically increased the total probe time for SCSI devices on larger configurations, because ses_enclosure_data_process() is called several times during the SCSI devices probe and loops over the component devices (but that is another problem, another patch). That results in a tremendous continuous hammering of SCSI Receive Diagnostics commands to the enclosure-services device, which does delay the total probe time for the SCSI devices __significantly__: Originally, ~34 minutes on a system attached to ~170 disks: [ 9214.490703] mpt3sas version 13.100.00.00 loaded ... [11256.580231] scsi 17:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) With this patch, it decreased to ~2.5 minutes -- a 13.6x faster [ 1002.992533] mpt3sas version 13.100.00.00 loaded ... [ 1151.978831] scsi 11:0:177:0: qdepth(16), tagged(1), simple(0), ordered(0), scsi_level(6), cmd_que(1) Back to the commit discussion.. on the ses_get_power_status() call introduced in ses_enclosure_data_process(): impact of removing it. That may possibly be in place to initialize the power status value on device probe. However, those 2 functions available to retrieve that value _do_ automatically refresh/update it. So the potential benefit would be a direct access of the 'power_status' field which does not use the callbacks... But the only reader of 'struct enclosure_component::power_status' is the get_component_power_status() callback for sysfs attribute, and it _does_ check for and call the .get_power_status callback, (which indeed is defined and implemented by that commit), so the power status value is, again, automatically updated. So, the remaining potential for a direct/non-callback access to the power_status attribute would be out-of-tree modules -- well, for those, if they are for whatever reason interested in values that are set during device probe and not up-to-date by the time they need it.. well, that would be curious. Well, to handle that more properly, set the initial power state value to '-1' (i.e., uninitialized) instead of '1' (power 'on'), and check for it in that callback which may do an direct access to the field value _if_ a callback function is not defined. Signed-off-by: Mauricio Faria de Oliveira Fixes: 08024885a2a3 ("ses: Add power_status to SES device slot") Reviewed-by: Dan Williams Reviewed-by: Song Liu Signed-off-by: Martin K. Petersen

scsi: ses: Fix SAS device detection in enclosure

2017-01-17T18:58:57Z

The call to scsi_is_sas_rphy() needs to be made on the SAS end_device, not on the SCSI device. Fixes: 835831c57e9b ("ses: use scsi_is_sas_rphy instead of is_sas_attached") Signed-off-by: Ewan D. Milne Reviewed-by: Johannes Thumshirn Reviewed-by: James Bottomley Signed-off-by: Martin K. Petersen

scsi: ses: use scsi_is_sas_rphy instead of is_sas_attached

2016-08-19T02:22:19Z

Use scsi_is_sas_rphy() instead of is_sas_attached() to decide whether we should obtain the SAS address from a scsi device or not. This will prevent us from tripping on the BUG_ON() in sas_sdev_to_rdev() if the rphy isn't attached to the SAS transport class, like it is with hpsa's logical devices. Fixes: 3f8d6f2a0 ('ses: fix discovery of SATA devices in SAS enclosures') Signed-off-by: Johannes Thumshirn Reviewed-by: James E.J. Bottomley Signed-off-by: Martin K. Petersen