lwn.git/drivers/scsi/storvsc_drv.c, branch v6.8-rc6

scsi: storvsc: Fix ring buffer size calculation

2024-01-24T02:27:28+00:00

Current code uses the specified ring buffer size (either the default of 128 Kbytes or a module parameter specified value) to encompass the one page ring buffer header plus the actual ring itself. When the page size is 4K, carving off one page for the header isn't significant. But when the page size is 64K on ARM64, only half of the default 128 Kbytes is left for the actual ring. While this doesn't break anything, the smaller ring size could be a performance bottleneck. Fix this by applying the VMBUS_RING_SIZE macro to the specified ring buffer size. This macro adds a page for the header, and rounds up the size to a page boundary, using the page size for which the kernel is built. Use this new size for subsequent ring buffer calculations. For example, on ARM64 with 64K page size and the default ring size, this results in the actual ring being 128 Kbytes, which is intended. Cc: stable@vger.kernel.org # 5.15.x Signed-off-by: Michael Kelley Link: https://lore.kernel.org/r/20240122170956.496436-1-mhklinux@outlook.com Signed-off-by: Martin K. Petersen

Merge branch '6.5/scsi-fixes' into 6.6/scsi-staging

2023-08-31T00:56:24+00:00

Pull in the fixes tree for a commit that missed 6.5. Also resolve a trivial merge conflict in fnic. * 6.5/scsi-fixes: (36 commits) scsi: storvsc: Handle additional SRB status values scsi: snic: Fix double free in snic_tgt_create() scsi: core: raid_class: Remove raid_component_add() scsi: ufs: ufs-qcom: Clear qunipro_g4_sel for HW major version > 5 scsi: ufs: mcq: Fix the search/wrap around logic scsi: qedf: Fix firmware halt over suspend and resume scsi: qedi: Fix firmware halt over suspend and resume scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock scsi: lpfc: Remove reftag check in DIF paths scsi: ufs: renesas: Fix private allocation scsi: snic: Fix possible memory leak if device_add() fails scsi: core: Fix possible memory leak if device_add() fails scsi: core: Fix legacy /proc parsing buffer overflow scsi: 53c700: Check that command slot is not NULL scsi: fnic: Replace return codes in fnic_clean_pending_aborts() scsi: storvsc: Fix handling of virtual Fibre Channel timeouts scsi: pm80xx: Fix error return code in pm8001_pci_probe() scsi: zfcp: Defer fc_rport blocking until after ADISC response scsi: storvsc: Limit max_sectors for virtual Fibre Channel devices scsi: sg: Fix checking return value of blk_get_queue() ... Signed-off-by: Martin K. Petersen

scsi: storvsc: Handle additional SRB status values

2023-08-25T21:10:02+00:00

Testing of virtual Fibre Channel devices under Hyper-V has shown additional SRB status values being returned for various error cases. Because these SRB status values are not recognized by storvsc, the I/O operations are not flagged as an error. Requests are treated as if they completed normally but with zero data transferred, which can cause a flood of retries. Add definitions for these SRB status values and handle them like other error statuses from the Hyper-V host. Signed-off-by: Michael Kelley Link: https://lore.kernel.org/r/1692984084-95105-1-git-send-email-mikelley@microsoft.com Signed-off-by: Martin K. Petersen

scsi: core: Improve type safety of scsi_rescan_device()

2023-08-25T02:11:29+00:00

Most callers of scsi_rescan_device() have the scsi_device pointer readily available. Pass a struct scsi_device pointer to scsi_rescan_device() instead of a struct device pointer. This change prevents that a pointer to another struct device would be passed accidentally to scsi_rescan_device(). Remove the scsi_rescan_device() declaration from the scsi_priv.h header file since it duplicates the declaration in . Reviewed-by: Hannes Reinecke Reviewed-by: Damien Le Moal Reviewed-by: John Garry Cc: Mike Christie Cc: Ming Lei Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20230822153043.4046244-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen

scsi: storvsc: Fix handling of virtual Fibre Channel timeouts

2023-07-31T18:23:28+00:00

Hyper-V provides the ability to connect Fibre Channel LUNs to the host system and present them in a guest VM as a SCSI device. I/O to the vFC device is handled by the storvsc driver. The storvsc driver includes a partial integration with the FC transport implemented in the generic portion of the Linux SCSI subsystem so that FC attributes can be displayed in /sys. However, the partial integration means that some aspects of vFC don't work properly. Unfortunately, a full and correct integration isn't practical because of limitations in what Hyper-V provides to the guest. In particular, in the context of Hyper-V storvsc, the FC transport timeout function fc_eh_timed_out() causes a kernel panic because it can't find the rport and dereferences a NULL pointer. The original patch that added the call from storvsc_eh_timed_out() to fc_eh_timed_out() is faulty in this regard. In many cases a timeout is due to a transient condition, so the situation can be improved by just continuing to wait like with other I/O requests issued by storvsc, and avoiding the guaranteed panic. For a permanent failure, continuing to wait may result in a hung thread instead of a panic, which again may be better. So fix the panic by removing the storvsc call to fc_eh_timed_out(). This allows storvsc to keep waiting for a response. The change has been tested by users who experienced a panic in fc_eh_timed_out() due to transient timeouts, and it solves their problem. In the future we may want to deprecate the vFC functionality in storvsc since it can't be fully fixed. But it has current users for whom it is working well enough, so it should probably stay for a while longer. Fixes: 3930d7309807 ("scsi: storvsc: use default I/O timeout handler for FC devices") Cc: stable@vger.kernel.org Signed-off-by: Michael Kelley Link: https://lore.kernel.org/r/1690606764-79669-1-git-send-email-mikelley@microsoft.com Signed-off-by: Martin K. Petersen

scsi: storvsc: Limit max_sectors for virtual Fibre Channel devices

2023-07-23T19:43:15+00:00

The Hyper-V host is queried to get the max transfer size that it supports, and this value is used to set max_sectors for the synthetic SCSI controller. However, this max transfer size may be too large for virtual Fibre Channel devices, which are limited to 512 Kbytes. If a larger transfer size is used with a vFC device, Hyper-V always returns an error, and storvsc logs a message like this where the SRB status and SCSI status are both zero: hv_storvsc : tag#197 cmd 0x8a status: scsi 0x0 srb 0x0 hv 0xc0000001 Add logic to limit the max transfer size to 512 Kbytes for vFC devices. Fixes: 1d3e0980782f ("scsi: storvsc: Correct reporting of Hyper-V I/O size limits") Cc: stable@vger.kernel.org Signed-off-by: Michael Kelley Link: https://lore.kernel.org/r/1689887102-32806-1-git-send-email-mikelley@microsoft.com Signed-off-by: Martin K. Petersen

scsi: storvsc: Handle SRB status value 0x30

2023-07-11T16:38:49+00:00

In response to a disk I/O request, Hyper-V has been observed to return SRB status value 0x30. This indicates the request was not processed by Hyper-V because low memory conditions on the host caused an internal error. The 0x30 status is not recognized by storvsc, so the I/O operation is not flagged as an error. The request is treated as if it completed normally but with zero data transferred, causing a flood of retries. Add a definition for this SRB status value and handle it like other error statuses from the Hyper-V host. Signed-off-by: Michael Kelley Link: https://lore.kernel.org/r/1688788886-94279-1-git-send-email-mikelley@microsoft.com Signed-off-by: Martin K. Petersen

scsi: storvsc: Always set no_report_opcodes

2023-06-15T01:32:48+00:00

Hyper-V synthetic SCSI devices do not support the MAINTENANCE_IN SCSI command, so scsi_report_opcode() always fails, resulting in messages like this: hv_storvsc : tag#205 cmd 0xa3 status: scsi 0x2 srb 0x86 hv 0xc0000001 The recently added support for command duration limits calls scsi_report_opcode() four times as each device comes online, which significantly increases the number of messages logged in a system with many disks. Fix the problem by always marking Hyper-V synthetic SCSI devices as not supporting scsi_report_opcode(). With this setting, the MAINTENANCE_IN SCSI command is not issued and no messages are logged. Signed-off-by: Michael Kelley Link: https://lore.kernel.org/r/1686343101-18930-1-git-send-email-mikelley@microsoft.com Signed-off-by: Martin K. Petersen

scsi: storvsc: Don't pass unused PFNs to Hyper-V host

2023-05-17T01:50:53+00:00

In a SCSI request, storvsc pre-allocates space for up to MAX_PAGE_BUFFER_COUNT physical frame numbers to be passed to Hyper-V. If the size of the I/O request requires more PFNs, a separate memory area of exactly the correct size is dynamically allocated. But when the pre-allocated area is used, current code always passes MAX_PAGE_BUFFER_COUNT PFNs to Hyper-V, even if fewer are needed. While this doesn't break anything because the additional PFNs are always zero, more bytes than necessary are copied into the VMBus channel ring buffer. This takes CPU cycles and wastes space in the ring buffer. For a typical 4 Kbyte I/O that requires only a single PFN, 248 unnecessary bytes are copied. Fix this by setting the payload_sz based on the actual number of PFNs required, not the size of the pre-allocated space. Reported-by: John Starks Fixes: 8f43710543ef ("scsi: storvsc: Support PAGE_SIZE larger than 4K") Signed-off-by: Michael Kelley Link: https://lore.kernel.org/r/1684171241-16209-1-git-send-email-mikelley@microsoft.com Signed-off-by: Martin K. Petersen

scsi: storvsc: Handle BlockSize change in Hyper-V VHD/VHDX file

2023-03-06T23:33:13+00:00

Hyper-V uses a VHD or VHDX file on the host as the underlying storage for a virtual disk. The VHD/VHDX file format is a sparse format where real disk space on the host is assigned in chunks that the VHD/VHDX file format calls the BlockSize. This BlockSize is not to be confused with the 512-byte (or 4096-byte) sector size of the underlying storage device. The default block size for a new VHD/VHDX file is 32 Mbytes. When a guest VM touches any disk space within a 32 Mbyte chunk of the VHD/VHDX file, Hyper-V allocates 32 Mbytes of real disk space for that section of the VHD/VHDX. Similarly, if a discard operation is done that covers an entire 32 Mbyte chunk, Hyper-V will free the real disk space for that portion of the VHD/VHDX. This BlockSize is surfaced in Linux as the "discard_granularity" in /sys/block/sd/queue, which makes sense. Hyper-V also has differencing disks that can overlay a VHD/VHDX file to capture changes to the VHD/VHDX while preserving the original VHD/VHDX. One example of this differencing functionality is for VM snapshots. When a snapshot is created, a differencing disk is created. If the snapshot is rolled back, Hyper-V can just delete the differencing disk, and the VM will see the original disk contents at the time the snapshot was taken. Differencing disks are used in other scenarios as well. The BlockSize for a differencing disk defaults to 2 Mbytes, not 32 Mbytes. The smaller default is used because changes to differencing disks are typically scattered all over, and Hyper-V doesn't want to allocate 32 Mbytes of real disk space for a stray write here or there. The smaller BlockSize provides more efficient use of real disk space. When a differencing disk is added to a VHD/VHDX, Hyper-V reports UNIT_ATTENTION with a sense code indicating "Operating parameters have changed", because the value of discard_granularity should be changed to 2 Mbytes. When the differencing disk is removed, discard_granularity should be changed back to 32 Mbytes. However, current code simply reports a message from scsi_report_sense() and the value of /sys/block/sd/queue/discard_granularity is not updated. The message isn't very actionable by a sysadmin. Fix this by having the storvsc driver check for the sense code indicating that the underly VHD/VHDX block size has changed, and do a rescan of the device to pick up the new discard_granularity. With this change the entire transition to/from differencing disks is handled automatically and transparently, with no confusing messages being output. Link: https://lore.kernel.org/r/1677516514-86060-1-git-send-email-mikelley@microsoft.com Signed-off-by: Michael Kelley Signed-off-by: Martin K. Petersen