kernel/linux.git/drivers/scsi/scsi.c, branch v6.2.2

scsi: core: Fix the scsi_device_put() might_sleep annotation

2023-01-27T03:01:31+00:00

Although most calls of scsi_device_put() happen from non-atomic context, alua_rtpg_queue() calls this function from atomic context if alua_rtpg_queue() itself is called from atomic context. alua_rtpg_queue() is always called from contexts where the caller must hold at least one reference to the scsi device in question. This means that the reference taken by alua_rtpg_queue() itself can't be the last one, and thus can be dropped without entering the code path in which scsi_device_put() might actually sleep. Hence move the might_sleep() annotation from scsi_device_put() into scsi_device_dev_release(). [1] https://lore.kernel.org/linux-scsi/b49e37d5-edfb-4c56-3eeb-62c7d5855c00@linux.ibm.com/ [2] https://lore.kernel.org/linux-scsi/55c35e64-a7d4-9072-46fd-e8eae6a90e96@linux.ibm.com/ Note: a significant part of the above description was written by Martin Wilck. Fixes: f93ed747e2c7 ("scsi: core: Release SCSI devices synchronously") Cc: Martin Wilck Cc: Steffen Maier Cc: Hannes Reinecke Cc: Sachin Sant Cc: Benjamin Block Reported-by: Steffen Maier Signed-off-by: Bart Van Assche Reviewed-by: Martin Wilck Link: https://lore.kernel.org/r/20230125194311.249553-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen

scsi: core: Release SCSI devices synchronously

2022-10-18T03:20:31+00:00

All upstream scsi_device_put() calls happen from thread context. Hence simplify scsi_device_put() by always calling the release function synchronously. This commit prepares for constifying the SCSI host template by removing an assignment that clears the module pointer in the SCSI host template. scsi_device_dev_release_usercontext() was introduced in 2006 via commit 65110b216895 ("[SCSI] fix wrong context bugs in SCSI"). Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Cc: John Garry Cc: Mike Christie Cc: Krzysztof Kozlowski Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20221015002418.30955-9-bvanassche@acm.org Signed-off-by: Martin K. Petersen

scsi: core: Remove the put_device() call from scsi_device_get()

2022-10-18T03:17:09+00:00

scsi_device_get() may be called from atomic context, e.g. by shost_for_each_device(). A later commit will allow put_device() to sleep for SCSI devices. Hence remove the put_device() call from scsi_device_get(). According to Rusty Russell's "Module Refcount and Stuff mini-FAQ", calling module_put() from atomic context is allowed since considerable time. See also https://lkml.org/lkml/2002/11/18/330. Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Cc: Mike Christie Cc: Krzysztof Kozlowski Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20221015002418.30955-8-bvanassche@acm.org Signed-off-by: Martin K. Petersen

scsi: core: Revert "Simplify LLD module reference counting"

2022-09-01T05:02:10+00:00

Revert the patch series "Call blk_mq_free_tag_set() earlier" because it introduces a deadlock if the scsi_remove_host() caller holds a reference on a device, target or host. Link: https://lore.kernel.org/r/20220821220502.13685-3-bvanassche@acm.org Fixes: 1a9283782df2 ("scsi: core: Simplify LLD module reference counting") Reported-by: syzbot+bafeb834708b1bb750bc@syzkaller.appspotmail.com Tested-by: Kenneth R. Crudup Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen

scsi: core: Simplify LLD module reference counting

2022-08-01T23:45:14+00:00

Swap two statements in scsi_device_put() now that it is guaranteed that SCSI hosts outlive SCSI devices. Remove the reference counting code from scsi_sysfs.c that became superfluous because SCSI hosts now outlive SCSI devices. Link: https://lore.kernel.org/r/20220728221851.1822295-4-bvanassche@acm.org Cc: Christoph Hellwig Cc: Ming Lei Cc: Mike Christie Cc: Hannes Reinecke Cc: John Garry Reviewed-by: Mike Christie Signed-off-by: Ming Lei Signed-off-by: Bart Van Assche [ bvanassche: Extracted this patch from a larger patch ] Signed-off-by: Martin K. Petersen

scsi: core: Cache VPD pages b0, b1, b2

2022-05-02T20:59:11+00:00

The SCSI disk driver consults VPD pages b0 (Block Limits), b1 (Block Device Characteristics), and b2 (Logical Block Provisioning). Instead of having sd.c request these pages every revalidate cycle, cache them along with the other commonly used VPDs. Link: https://lore.kernel.org/r/20220302053559.32147-6-martin.petersen@oracle.com Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen

scsi: core: Pick suitable allocation length in scsi_report_opcode()

2022-05-02T20:59:10+00:00

Some devices hang when a buffer size larger than expected is passed in the ALLOCATION LENGTH field. For REPORT SUPPORTED OPERATION CODES we currently only request a single command descriptor at a time and therefore the actual size of the command is known ahead of time. Limit the ALLOCATION LENGTH to the header size plus the command length of the opcode we are asking about. Link: https://lore.kernel.org/r/20220302053559.32147-5-martin.petersen@oracle.com Reviewed-by: Hannes Reinecke Reviewed-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen

scsi: core: Query VPD size before getting full page

2022-05-02T20:59:10+00:00

We currently default to 255 bytes when fetching VPD pages during discovery. However, we have had a few devices that are known to wedge if the requested buffer exceeds a certain size. See commit af73623f5f10 ("[SCSI] sd: Reduce buffer size for vpd request") which works around one example of this problem in the SCSI disk driver. With commit d188b0675b21 ("scsi: core: Add sysfs attributes for VPD pages 0h and 89h") we now risk triggering the same issue in the generic midlayer code. The problem with the ATA VPD page in particular is that the SCSI portion of the page is trailed by 512 bytes of verbatim ATA Identify Device information. However, not all controllers actually provide the additional 512 bytes and will lock up if one asks for more than the 64 bytes containing the SCSI protocol fields. Instead of picking a new, somewhat arbitrary, number of bytes for the VPD buffer size, start fetching the 4-byte header for each page. The header contains the size of the page as far as the device is concerned. We can use the reported size to specify the correct allocation length when subsequently fetching the full page. The header validation is done by a new helper function scsi_get_vpd_size() and both scsi_get_vpd_page() and scsi_get_vpd_buf() now rely on this to query the page size. In addition, scsi_get_vpd_page() is simplified to mirror the logic in scsi_get_vpd_page(). This involves removing the Supported VPD Pages lookup prior to attempting to query a page. There does not appear any evidence, even in the oldest SCSI specs, that this step is required. We already rely on scsi_get_vpd_page() throughout the stack and this function never consulted the Supported VPD Pages. Since this has not caused any problems it should be safe to remove the precondition from scsi_get_vpd_page(). Instrumented runs also revealed that the Supported VPD Pages lookup had little effect since the device page index often was larger than the supplied buffer size. As a result, inquiries frequently bypassed the index check and went through the "If we ran off the end of the buffer, give us the benefit of the doubt" code path which assumed the page was present despite not being listed. The revised code takes both the page size reported by the device as well as the size of the buffer provided by the scsi_get_vpd_page() caller into account. Link: https://lore.kernel.org/r/20220302053559.32147-3-martin.petersen@oracle.com Fixes: d188b0675b21 ("scsi: core: Add sysfs attributes for VPD pages 0h and 89h") Reported-by: Maciej W. Rozycki Tested-by: Maciej W. Rozycki Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen

scsi: core: Increase max device queue_depth to 4096

2022-04-19T03:02:47+00:00

The maximum SCSI device queue depth of 1024 is not sufficient for RAID volumes configured behind Broadcom RAID controllers. For a 16-drive RAID volume with a device queue depth limit of 1024, only 64 I/Os (1024/16) can be issued per drive. That is not sufficient to saturate the device. Link: https://lore.kernel.org/r/20220414103601.140687-1-sumit.saxena@broadcom.com Cc: Ming Lei Cc: Hannes Reinecke Cc: Bart Van Assche Cc: Sumanesh Samanta Signed-off-by: Sumit Saxena Signed-off-by: Martin K. Petersen

scsi: core: Fix scsi_device_max_queue_depth()

2021-12-07T03:30:32+00:00

The comment above scsi_device_max_queue_depth() and also the description of commit ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <= max(shost->can_queue, 1024)") contradict the implementation of the function scsi_device_max_queue_depth(). Additionally, the maximum queue depth of a SCSI LUN never exceeds host->can_queue. Fix scsi_device_max_queue_depth() by changing max_t() into min_t(). Link: https://lore.kernel.org/r/20211203231950.193369-2-bvanassche@acm.org Fixes: ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <= max(shost->can_queue, 1024)") Cc: Hannes Reinecke Cc: Sumanesh Samanta Tested-by: Bean Huo Reviewed-by: Ming Lei Reviewed-by: Bean Huo Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen