aboutsummaryrefslogtreecommitdiff
path: root/drivers/scsi
AgeCommit message (Collapse)AuthorFilesLines
2024-08-12scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfersFinn Thain1-0/+4
Following an incomplete transfer in MSG IN phase, the driver would not notice the problem and would make use of invalid data. Initialize 'tmp' appropriately and bail out if no message was received. For STATUS phase, preserve the existing status code unless a new value was transferred. Tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Link: https://lore.kernel.org/r/52e02a8812ae1a2d810d7f9f7fd800c3ccc320c4.1723001788.git.fthain@linux-m68k.org Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mac_scsi: Enable scatter/gather by defaultFinn Thain1-1/+7
Now that FLAG_DMA_FIXUP has itself been fixed up, it can be used to enable scatter/gather. Increase the default value for sg_tablesize to SG_ALL for those systems which are compatible with FLAG_DMA_FIXUP. Tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Link: https://lore.kernel.org/r/f155ba5ce93055cbc6ac6d4026673f40f826edb8.1723001788.git.fthain@linux-m68k.org Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: NCR5380: Check for phase match during PDMA fixupFinn Thain1-39/+39
It's not an error for a target to change the bus phase during a transfer. Unfortunately, the FLAG_DMA_FIXUP workaround does not allow for that -- a phase change produces a DRQ timeout error and the device borken flag will be set. Check the phase match bit during FLAG_DMA_FIXUP processing. Don't forget to decrement the command residual. While we are here, change shost_printk() into scmd_printk() for better consistency with other DMA error messages. Tested-by: Stan Johnson <[email protected]> Fixes: 55181be8ced1 ("ncr5380: Replace redundant flags with FLAG_NO_DMA_FIXUP") Signed-off-by: Finn Thain <[email protected]> Link: https://lore.kernel.org/r/99dc7d1f4c825621b5b120963a69f6cd3e9ca659.1723001788.git.fthain@linux-m68k.org Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mac_scsi: Disallow bus errors during PDMA sendFinn Thain1-25/+19
SD cards can produce write latency spikes on the order of a hundred milliseconds. If the target firmware does not hide that latency during DATA IN and OUT phases it can cause the PDMA circuitry to raise a processor bus fault which in turn leads to an unreliable byte count and a DMA overrun. The Last Byte Sent flag is used to detect the overrun but this mechanism is unreliable on some systems. Instead, set a DID_ERROR result whenever there is a bus fault during a PDMA send, unless the cause was a phase mismatch. Cc: [email protected] # 5.15+ Reported-and-tested-by: Stan Johnson <[email protected]> Fixes: 7c1f3e3447a1 ("scsi: mac_scsi: Treat Last Byte Sent time-out as failure") Signed-off-by: Finn Thain <[email protected]> Link: https://lore.kernel.org/r/cc38df687ace2c4ffc375a683b2502fc476b600d.1723001788.git.fthain@linux-m68k.org Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mac_scsi: Refactor polling loopFinn Thain1-38/+42
Before the error handling can be revised, some preparation is needed. Refactor the polling loop with a new function, macscsi_wait_for_drq(). This function will gain more call sites in the next patch. Cc: [email protected] # 5.15+ Tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Link: https://lore.kernel.org/r/6a5ffabb4290c0d138c6d285fda8fa3902e926f0.1723001788.git.fthain@linux-m68k.org Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messagesFinn Thain1-20/+22
After a bus fault, capture and log the chip registers immediately, if the NDEBUG_PSEUDO_DMA macro is defined. Remove some printk(KERN_DEBUG ...) messages that aren't needed any more. Don't skip the debug message when bytes == 0. Show all of the byte counters in the debug messages. Cc: [email protected] # 5.15+ Tested-by: Stan Johnson <[email protected]> Signed-off-by: Finn Thain <[email protected]> Link: https://lore.kernel.org/r/7573c79f4e488fc00af2b8a191e257ca945e0409.1723001788.git.fthain@linux-m68k.org Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mpi3mr: Driver version update to 8.10.0.5.50Ranjan Kumar1-2/+2
Update driver version to 8.10.0.5.50. Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mpi3mr: Update consumer index of reply queues after every 100 repliesRanjan Kumar2-2/+17
Instead of updating the ConsumerIndex of the Admin and Operational ReplyQueues after processing all replies in the queue, the index will now be periodically updated after processing every 100 replies. Co-developed-by: Sathya Prakash <[email protected]> Signed-off-by: Sathya Prakash <[email protected]> Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mpi3mr: Return complete ioc_status for ioctl commandsRanjan Kumar1-5/+9
The driver masked the loginfo available bit in the iocstatus before passing it to the applications, causing a mismatch in error messages between Linux and other operating systems. Modify driver to return unmasked (complete) iocstatus, including the loginfo available bit, for the MPI commands sent through the ioctl interface. Co-developed-by: Sathya Prakash <[email protected]> Signed-off-by: Sathya Prakash <[email protected]> Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: snic: Avoid creating two slab caches with the same namePedro Falcato1-1/+1
In the spirit of [1], fix the copy-paste typo and use unique names for both caches. [1]: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Pedro Falcato <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mpi3mr: Avoid MAX_PAGE_ORDER WARNING for buffer allocationsShin'ichiro Kawasaki1-3/+8
Commit fc4444941140 ("scsi: mpi3mr: HDB allocation and posting for hardware and firmware buffers") added mpi3mr_alloc_diag_bufs() which calls dma_alloc_coherent() to allocate the trace buffer and the firmware buffer. mpi3mr_alloc_diag_bufs() decides the buffer sizes from the driver configuration. In my environment, the sizes are 8MB. With the sizes, dma_alloc_coherent() fails and report this WARNING: WARNING: CPU: 4 PID: 438 at mm/page_alloc.c:4676 __alloc_pages_noprof+0x52f/0x640 The WARNING indicates that the order of the allocation size is larger than MAX_PAGE_ORDER. After this failure, mpi3mr_alloc_diag_bufs() reduces the buffer sizes and retries dma_alloc_coherent(). In the end, the buffer allocations succeed with 4MB size in my environment, which corresponds to MAX_PAGE_ORDER=10. Though the allocations succeed, the WARNING message is misleading and should be avoided. To avoid the WARNING, check the orders of the buffer allocation sizes before calling dma_alloc_coherent(). If the orders are larger than MAX_PAGE_ORDER, fall back to the retry path. Fixes: fc4444941140 ("scsi: mpi3mr: HDB allocation and posting for hardware and firmware buffers") Signed-off-by: Shin'ichiro Kawasaki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Sathya Prakash Veerichetty <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: mpi3mr: Add missing spin_lock_init() for mrioc->trigger_lockShin'ichiro Kawasaki1-0/+1
Commit fc4444941140 ("scsi: mpi3mr: HDB allocation and posting for hardware and firmware buffers") added the spinlock trigger_lock to the struct mpi3mr_ioc. However, spin_lock_init() call was not added for it, then the lock does not work as expected. Also, the kernel reports the message below when lockdep is enabled. INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? To fix the issue and to avoid the INFO message, add the missing spin_lock_init() call. Fixes: fc4444941140 ("scsi: mpi3mr: HDB allocation and posting for hardware and firmware buffers") Signed-off-by: Shin'ichiro Kawasaki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Sathya Prakash Veerichetty <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-12scsi: sd: Don't check if a write for REQ_ATOMICJohn Garry1-1/+1
Flag REQ_ATOMIC can only be set for writes, so don't check if the operation is also a write in sd_setup_read_write_cmnd(). Fixes: bf4ae8f2e640 ("scsi: sd: Atomic write support") Signed-off-by: John Garry <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Kanchan Joshi <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-11Merge tag 'scsi-fixes' of ↵Linus Torvalds1-5/+10
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Two core fixes: one to prevent discard type changes (seen on iSCSI) during intermittent errors and the other is fixing a lockdep problem caused by the queue limits change. And one driver fix in ufs" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sd: Keep the discard mode stable scsi: sd: Move sd_read_cpr() out of the q->limits_lock region scsi: ufs: core: Fix hba->last_dme_cmd_tstamp timestamp updating logic
2024-08-03Merge tag 'scsi-fixes' of ↵Linus Torvalds3-4/+32
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "One core change that reverts the double message print patch in sd.c (it was causing regressions on embedded systems). The rest are driver fixes in ufs, mpt3sas and mpi3mr" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: exynos: Don't resume FMP when crypto support is disabled scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES scsi: mpi3mr: Avoid IOMMU page faults on REPORT ZONES scsi: ufs: core: Do not set link to OFF state while waking up from hibernation scsi: Revert "scsi: sd: Do not repeat the starting disk message" scsi: ufs: core: Fix deadlock during RTC update scsi: ufs: core: Bypass quick recovery if force reset is needed scsi: ufs: core: Check LSDBS cap when !mcq
2024-08-02Merge patch series "smartpqi updates"Martin K. Petersen2-27/+151
Don Brace <[email protected]> says: These patches are based on Martin Petersen's 6.11/scsi-queue tree https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git 6.11/scsi-queue The functional changes of note to smartpqi are for: multipath failover and improving the accuracy of our RAID bypass counter. For multipath we are: Reverting commit 94a68c814328 ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer") because under certain rare conditions involving encryption-enabled devices, a false path failure is reported to the SML causing multipath to failover to the other path. Improving errors returned from the driver back to the SML by checking for error codes returned from the firmware and returning the correct ASC/ASCQ codes to the SML. The other two patches add PCI-IDs for new controllers and change the driver version. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: Update driver version to 2.1.28-025Don Brace1-3/+3
Update driver version to 2.1.28-025. Reviewed-by: Mike Tran <[email protected]> Reviewed-by: Gerry Morong <[email protected]> Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: Improve handling of multipath failoverKevin Barnett1-1/+15
Improve multipath failovers by mapping firmware errors into I/O errors. In some rare instances, firmware does not return the proper error code for I/O errors caused by a multipath path failure. Map I/O errors returned by firmware into errors that help the multipath layer to detect the failure of a path. Reviewed-by: Gerry Morong <[email protected]> Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Signed-off-by: Kevin Barnett <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quicklyGilbert Wu1-18/+2
Correct a rare multipath failure issue by reverting commit 94a68c814328 ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer") [1]. Reason for revert: The patch propagated the path failure to SML quickly when one of the path fails during IO and AIO path gets disabled for a multipath device. But it created a new issue: when creating a volume on an encryption-enabled controller, the firmware reports the AIO path is disabled, which cause the driver to report a path failure to SML for a multipath device. There will be a new fix to handle "Illegal request" and "Invalid field in parameter list" on RAID path when the AIO path is disabled on a multipath device. [1] https://lore.kernel.org/all/[email protected]/ Fixes: 94a68c814328 ("scsi: smartpqi: Quickly propagate path failures to SCSI midlayer") Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Signed-off-by: Gilbert Wu <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: Improve accuracy/performance of raid-bypass-counterKevin Barnett2-5/+27
The original implementation of this counter used an atomic variable. However, this implementation negatively impacted performance in some configurations. Switch to using per_cpu variables. Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Co-developed-by: Mahesh Rajashekhara <[email protected]> Signed-off-by: Mahesh Rajashekhara <[email protected]> Signed-off-by: Kevin Barnett <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: smartpqi: Add new controller PCI IDsDavid Strahan1-0/+104
All PCI ID entries in hex. Add new inagile PCI IDs: VID / DID / SVID / SDID ---- ---- ---- ---- SMART-HBA 8242-24i 9005 / 028f / 1ff9 / 0045 RAID 8236-16i 9005 / 028f / 1ff9 / 0046 RAID 8240-24i 9005 / 028f / 1ff9 / 0047 SMART-HBA 8238-16i 9005 / 028f / 1ff9 / 0048 PM8222-SHBA 9005 / 028f / 1ff9 / 004a RAID PM8204-2GB 9005 / 028f / 1ff9 / 004b RAID PM8204-4GB 9005 / 028f / 1ff9 / 004c PM8222-HBA 9005 / 028f / 1ff9 / 004f MT0804M6R 9005 / 028f / 1ff9 / 0051 MT0801M6E 9005 / 028f / 1ff9 / 0052 MT0808M6R 9005 / 028f / 1ff9 / 0053 MT0800M6H 9005 / 028f / 1ff9 / 0054 RS0800M5H24i 9005 / 028f / 1ff9 / 006b RS0800M5E8i 9005 / 028f / 1ff9 / 006c RS0800M5H8i 9005 / 028f / 1ff9 / 006d RS0804M5R16i 9005 / 028f / 1ff9 / 006f RS0800M5E24i 9005 / 028f / 1ff9 / 0070 RS0800M5H16i 9005 / 028f / 1ff9 / 0071 RS0800M5E16i 9005 / 028f / 1ff9 / 0072 RT0800M7E 9005 / 028f / 1ff9 / 0086 RT0800M7H 9005 / 028f / 1ff9 / 0087 RT0804M7R 9005 / 028f / 1ff9 / 0088 RT0808M7R 9005 / 028f / 1ff9 / 0089 RT1608M6R16i 9005 / 028f / 1ff9 / 00a1 Add new h3c pci_id: VID / DID / SVID / SDID ---- ---- ---- ---- UN RAID P4408-Mr-2 9005 / 028f / 193d / 1110 Add new powerleader pci ids: VID / DID / SVID / SDID ---- ---- ---- ---- PL SmartROC PM8204 9005 / 028f / 1f3a / 0104 Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Signed-off-by: David Strahan <[email protected]> Signed-off-by: Don Brace <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: sd: Keep the discard mode stableLi Feng1-4/+2
There is a scenario where a large number of discard commands are issued when the iscsi initiator connects to the target and then performs a session rescan operation. There is a time window, most of the commands are in UNMAP mode, and some discard commands become WRITE SAME with UNMAP. The discard mode has been negotiated during the SCSI probe. If the mode is temporarily changed from UNMAP to WRITE SAME with UNMAP, an I/O ERROR may occur because the target may not implement WRITE SAME with UNMAP. Keep the discard mode stable to fix this issue. Signed-off-by: Li Feng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02Merge patch series "Update lpfc to revision 14.4.0.4"Martin K. Petersen8-46/+112
Justin Tee <[email protected]> says: Update lpfc to revision 14.4.0.4 This patch set contains diagnostic logging improvements, a minor clean up when submitting abort requests, a bug fix related to reset and errata paths, and modifications to FLOGI and PRLO ELS command handling. The patches were cut against Martin's 6.11/scsi-queue tree. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Copyright updates for 14.4.0.4 patchesJustin Tee1-1/+1
Update copyrights to 2024 for files modified in the 14.4.0.4 patch set. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Update lpfc version to 14.4.0.4Justin Tee1-1/+1
Update lpfc version to 14.4.0.4 Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Update PRLO handling in direct attached topologyJustin Tee2-13/+36
A kref imbalance occurs when handling an unsolicited PRLO in direct attached topology. Rework PRLO rcv handling when in MAPPED state. Save the state that we were handling a PRLO by setting nlp_last_elscmd to ELS_CMD_PRLO. Then in the lpfc_cmpl_els_logo_acc() completion routine, manually restart discovery. By issuing the PLOGI, which nlp_gets, before nlp_put at the end of the lpfc_cmpl_els_logo_acc() routine, we are saving us from a final nlp_put. And, we are still allowing the unreg_rpi to happen. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached ↵Justin Tee3-23/+46
topology In direct attached topology, certain target vendors that are quick to issue FLOGI followed by a cable pull for more than dev_loss_tmo may result in a kref imbalance for the remote port ndlp object. Add an nlp_get when the defer_flogi_acc flag is set. This is expected to balance the nlp_put in the defer_flogi_acc clause in the lpfc_issue_els_flogi() routine. Because we need to retain the ndlp ptr, reorganize all of the defer_flogi_acc information into one lpfc_defer_flogi_acc struct. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Fix unintentional double clearing of vmid_flagJustin Tee2-2/+3
The vport->vmid_flag is unintentionally cleared twice after an issue_lip via the lpfc_reinit_vmid routine(). The first call to lpfc_reinit_vmid() is in lpfc_cmpl_els_flogi(). Then lpfc_cmpl_els_flogi_fabric() calls lpfc_register_new_vport(), which calls lpfc_cmpl_reg_new_vport() when the mbox command completes and calls lpfc_reinit_vmid() a second time. Fix by moving the vmid_flag clear outside of the lpfc_reinit_vmid() routine so that vmid_flag is only cleared once upon FLOGI completion. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata pathsJustin Tee3-3/+24
When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Remove redundant vport assignment when building an abort requestJustin Tee1-2/+0
The lpfc_sli_issue_abort_iotag() routine has a redundant assignment of abtsiocbp->vport = vport; The duplicate lines are from a previous refactoring, and this patch removes the accidental redundancy. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: lpfc: Change diagnostic log flag during receipt of unknown ELS cmdsJustin Tee1-1/+1
During diagnostics, it has been determined that the 0115 log message for receipt of unknown ELS cmds does not benefit from trace buffer dumps. The trace buffer dump floods the console with unnecessary information, and the singular LOG_ELS flag has proven more beneficial in debugging efforts when dealing with unknown ELS cmds. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02Merge patch series "scsi: aacraid: struct sgmap: Replace 1-element arrays ↵Martin K. Petersen5-31/+24
with flexible arrays" Kees Cook <[email protected]> says: This replaces some of the last remaining uses in the kernel of 1-element "fake" flexible arrays with modern C99 flexible arrays. Some refactoring is done to ease this, and binary differences are identified. For the on stack size changes in patch 2, the "yes, that is the source of the binary differences" debugging patch can be found here[1]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=dev/v6.10-rc2/1-element&id=45e6226bcbc5e982541754eca7ac29f403e82f5e Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: aacraid: struct {user,}sgmap{,64,raw}: Replace 1-element arrays with ↵Kees Cook5-30/+23
flexible arrays Replace the deprecated[1] use of 1-element arrays in struct sgmap, struct sgmap64, struct sgmapraw, struct user_sgmap, and struct user_sgmap64 with modern flexible arrays. Additionally remove struct user_sgmapraw as it is unused. The resulting binary output differences from this change are limited only to stack space consumption of the smaller "srbu" variable in aac_issue_safw_bmic_identify() and aac_get_safw_ciss_luns(), as well as the smaller associated pair of memcpy()s in aac_send_safw_bmic_cmd(). Artificially growing the size of srbu back to its prior size removes all binary differences[2]. As an aside, after studying the aacraid driver code I wonder how aac_send_wellness_command() ever works. It is reporting a size 4 bytes too small for what it has constructed in memory in the DMA region: sgentry64 is size 12, whereas sgentry is size 8. Perhaps the hardware doesn't care. (Regardless, it is unchanged by this patch.) Link: https://github.com/KSPP/linux/issues/79 [1] Link: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=dev/v6.10-rc2/1-element&id=45e6226bcbc5e982541754eca7ac29f403e82f5e [2] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: aacraid: Rearrange order of struct aac_srb_unitKees Cook1-1/+1
struct aac_srb_unit contains struct aac_srb, which contains struct sgmap, which ends in a (currently) "fake" (1-element) flexible array. Converting this to a flexible array is needed so that runtime bounds checking won't think the array is fixed size (i.e. under CONFIG_FORTIFY_SOURCE=y and/or CONFIG_UBSAN_BOUNDS=y), as other parts of aacraid use struct sgmap as a flexible array. It is not legal to have a flexible array in the middle of a structure, so it either needs to be split up or rearranged so that it is at the end of the structure. Luckily, struct aac_srb_unit, which is exclusively consumed/updated by aac_send_safw_bmic_cmd(), does not depend on member ordering. The values set in the on-stack struct aac_srb_unit instance "srbu" by the only two callers, aac_issue_safw_bmic_identify() and aac_get_safw_ciss_luns(), do not contain anything in srbu.srb.sgmap.sg, and they both implicitly initialize srbu.srb.sgmap.count to 0 during memset(). For example: memset(&srbu, 0, sizeof(struct aac_srb_unit)); srbcmd = &srbu.srb; srbcmd->flags = cpu_to_le32(SRB_DataIn); srbcmd->cdb[0] = CISS_REPORT_PHYSICAL_LUNS; srbcmd->cdb[1] = 2; /* extended reporting */ srbcmd->cdb[8] = (u8)(datasize >> 8); srbcmd->cdb[9] = (u8)(datasize); rcode = aac_send_safw_bmic_cmd(dev, &srbu, phys_luns, datasize); During aac_send_safw_bmic_cmd(), a separate srb is mapped into DMA, and has srbu.srb copied into it: srb = fib_data(fibptr); memcpy(srb, &srbu->srb, sizeof(struct aac_srb)); Only then is srb.sgmap.count written and srb->sg populated: srb->count = cpu_to_le32(xfer_len); sg64 = (struct sgmap64 *)&srb->sg; sg64->count = cpu_to_le32(1); sg64->sg[0].addr[1] = cpu_to_le32(upper_32_bits(addr)); sg64->sg[0].addr[0] = cpu_to_le32(lower_32_bits(addr)); sg64->sg[0].count = cpu_to_le32(xfer_len); But this is happening in the DMA memory, not in srbu.srb. An attempt to copy the changes back to srbu does happen: /* * Copy the updated data for other dumping or other usage if * needed */ memcpy(&srbu->srb, srb, sizeof(struct aac_srb)); But this was never correct: the sg64 (3 u32s) overlap of srb.sg (2 u32s) always meant that srbu.srb would have held truncated information and any attempt to walk srbu.srb.sg.sg based on the value of srbu.srb.sg.count would result in attempting to parse past the end of srbu.srb.sg.sg[0] into srbu.srb_reply. After getting a reply from hardware, the reply is copied into srbu.srb_reply: srb_reply = (struct aac_srb_reply *)fib_data(fibptr); memcpy(&srbu->srb_reply, srb_reply, sizeof(struct aac_srb_reply)); This has always been fixed-size, so there's no issue here. It is worth noting that the two callers _never check_ srbu contents -- neither srbu.srb nor srbu.srb_reply is examined. (They depend on the mapped xfer_buf instead.) Therefore, the ordering of members in struct aac_srb_unit does not matter, and the flexible array member can moved to the end. (Additionally, the two memcpy()s that update srbu could be entirely removed as they are never consumed, but I left that as-is.) Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: ipr: Replace 1-element arrays with flexible arraysKees Cook1-2/+2
Replace the deprecated[1] use of a 1-element arrays in struct ipr_hostrcb_fabric_desc and struct ipr_hostrcb64_fabric_desc with modern flexible arrays. No binary differences are present after this conversion. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: aacraid: struct aac_ciss_phys_luns_resp: Replace 1-element array with ↵Kees Cook2-2/+2
flexible array Replace the deprecated[1] use of a 1-element array in struct aac_ciss_phys_luns_resp with a modern flexible array. No binary differences are present after this conversion. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: aacraid: union aac_init: Replace 1-element array with flexible arrayKees Cook2-2/+2
Replace the deprecated[1] use of a 1-element array in union aac_init with a modern flexible array. Additionally add __counted_by annotation since rrq is only ever accessed after rr_queue_count has been set (with the same value used to control the loop): init->r8.rr_queue_count = cpu_to_le32(dev->max_msix); ... for (i = 0; i < dev->max_msix; i++) { addr = (u64)dev->host_rrq_pa + dev->vector_cap * i * sizeof(u32); init->r8.rrq[i].host_addr_high = cpu_to_le32( upper_32_bits(addr)); No binary differences are present after this conversion. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: megaraid_sas: struct MR_HOST_DEVICE_LIST: Replace 1-element array with ↵Kees Cook1-2/+2
flexible array Replace the deprecated[1] use of a 1-element array in struct MR_HOST_DEVICE_LIST with a modern flexible array. One binary difference appears in megasas_host_device_list_query(): struct MR_HOST_DEVICE_LIST *ci; ... ci = instance->host_device_list_buf; ... memset(ci, 0, sizeof(*ci)); The memset() clears only the non-flexible array fields. Looking at the rest of the function, this appears to be fine: firmware is using this region to communicate with the kernel, so it likely never made sense to clear the first MR_HOST_DEVICE_LIST_ENTRY. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: megaraid_sas: struct MR_LD_VF_MAP: Replace 1-element arrays with ↵Kees Cook1-1/+1
flexible arrays Replace the deprecated[1] use of a 1-element array in struct MR_LD_VF_MAP with a modern flexible array. No binary differences are present after this conversion. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: mpi3mr: struct mpi3_sas_io_unit_page1: Replace 1-element array with ↵Kees Cook1-4/+1
flexible array Replace the deprecated[1] use of a 1-element array in struct mpi3_sas_io_unit_page1 with a modern flexible array. No binary differences are present after this conversion. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: mpi3mr: struct mpi3_sas_io_unit_page0: Replace 1-element array with ↵Kees Cook1-4/+1
flexible array Replace the deprecated[1] use of a 1-element array in struct mpi3_sas_io_unit_page0 with a modern flexible array. No binary differences are present after this conversion. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: mpi3mr: struct mpi3_event_data_pcie_topology_change_list: Replace ↵Kees Cook1-4/+1
1-element array with flexible array Replace the deprecated[1] use of a 1-element array in struct mpi3_event_data_pcie_topology_change_list with a modern flexible array. Additionally add __counted_by annotation since port_entry is only ever accessed in loops controlled by num_entries. For example: for (i = 0; i < event_data->num_entries; i++) { handle = le16_to_cpu(event_data->port_entry[i].attached_dev_handle); No binary differences are present after this conversion. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02scsi: mpi3mr: struct mpi3_event_data_sas_topology_change_list: Replace ↵Kees Cook1-4/+1
1-element array with flexible array Replace the deprecated[1] use of a 1-element array in struct mpi3_event_data_sas_topology_change_list with a modern flexible array. Additionally add __counted_by annotation since phy_entry is only ever accessed in loops controlled by num_entries. For example: for (i = 0; i < event_data->num_entries; i++) { ... handle = le16_to_cpu(event_data->phy_entry[i].attached_dev_handle); No binary differences are present after this conversion. Link: https://github.com/KSPP/linux/issues/79 [1] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-01scsi: sd: Move sd_read_cpr() out of the q->limits_lock regionShin'ichiro Kawasaki1-1/+8
Commit 804e498e0496 ("sd: convert to the atomic queue limits API") introduced pairs of function calls to queue_limits_start_update() and queue_limits_commit_update(). These two functions lock and unlock q->limits_lock. In sd_revalidate_disk(), sd_read_cpr() is called after queue_limits_start_update() call and before queue_limits_commit_update() call. sd_read_cpr() locks q->sysfs_dir_lock and &q->sysfs_lock. Then new lock dependencies were created between q->limits_lock, q->sysfs_dir_lock and q->sysfs_lock, as follows: sd_revalidate_disk queue_limits_start_update mutex_lock(&q->limits_lock) sd_read_cpr disk_set_independent_access_ranges mutex_lock(&q->sysfs_dir_lock) mutex_lock(&q->sysfs_lock) mutex_unlock(&q->sysfs_lock) mutex_unlock(&q->sysfs_dir_lock) queue_limits_commit_update mutex_unlock(&q->limits_lock) However, the three locks already had reversed dependencies in other places. Then the new dependencies triggered the lockdep WARN "possible circular locking dependency detected" [1]. This WARN was observed by running the blktests test case srp/002. To avoid the WARN, move the sd_read_cpr() call in sd_revalidate_disk() after the queue_limits_commit_update() call. In other words, move the sd_read_cpr() call out of the q->limits_lock region. [1] https://lore.kernel.org/linux-scsi/vlmv53ni3ltwxplig5qnw4xsl2h6ccxijfbqzekx76vxoim5a5@dekv7q3es3tx/ Fixes: 804e498e0496 ("sd: convert to the atomic queue limits API") Signed-off-by: Shin'ichiro Kawasaki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Luca Coelho <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2024-08-02ata: libata: Remove ata_noop_qc_prep()Damien Le Moal1-1/+0
The function ata_noop_qc_prep(), as its name implies, does nothing and simply returns AC_ERR_OK. For drivers that do not need any special preparations of queued commands, we can avoid having to define struct ata_port qc_prep operation by simply testing if that operation is defined or not in ata_qc_issue(). Make this change and remove ata_noop_qc_prep(). Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: John Garry <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]>
2024-07-29Merge branch '6.11/scsi-queue' into 6.11/scsi-fixesMartin K. Petersen3-4/+32
Pull outstanding commits from 6.11 queue into fixes. Signed-off-by: Martin K. Petersen <[email protected]>
2024-07-28minmax: scsi: fix mis-use of 'clamp()' in sr.cLinus Torvalds1-1/+1
While working on simplifying the minmax functions, and avoiding excessive macro expansion, it turns out that the sr.c use of the 'clamp()' macro has the arguments the wrong way around. The clamp logic is val = clamp(in, low, high); and it returns the input clamped to the low/high limits. But sr.c ddid speed = clamp(0, speed, 0xffff / 177); which clamps the value '0' to the range '[speed, 0xffff / 177]' and ends up being nonsensical. Happily, I don't think anybody ever cared. Fixes: 9fad9d560af5 ("scsi: sr: Fix unintentional arithmetic wraparound") Cc: Justin Stitt <[email protected]> Cc: Kees Cook <[email protected]> Cc: Martin K. Petersen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2024-07-28minmax: make generic MIN() and MAX() macros available everywhereLinus Torvalds1-5/+1
This just standardizes the use of MIN() and MAX() macros, with the very traditional semantics. The goal is to use these for C constant expressions and for top-level / static initializers, and so be able to simplify the min()/max() macros. These macro names were used by various kernel code - they are very traditional, after all - and all such users have been fixed up, with a few different approaches: - trivial duplicated macro definitions have been removed Note that 'trivial' here means that it's obviously kernel code that already included all the major kernel headers, and thus gets the new generic MIN/MAX macros automatically. - non-trivial duplicated macro definitions are guarded with #ifndef This is the "yes, they define their own versions, but no, the include situation is not entirely obvious, and maybe they don't get the generic version automatically" case. - strange use case #1 A couple of drivers decided that the way they want to describe their versioning is with #define MAJ 1 #define MIN 2 #define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) which adds zero value and I just did my Alexander the Great impersonation, and rewrote that pointless Gordian knot as #define DRV_VERSION "1.2" instead. - strange use case #2 A couple of drivers thought that it's a good idea to have a random 'MIN' or 'MAX' define for a value or index into a table, rather than the traditional macro that takes arguments. These values were re-written as C enum's instead. The new function-line macros only expand when followed by an open parenthesis, and thus don't clash with enum use. Happily, there weren't really all that many of these cases, and a lot of users already had the pattern of using '#ifndef' guarding (or in one case just using '#undef MIN') before defining their own private version that does the same thing. I left such cases alone. Cc: David Laight <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2024-07-25Merge tag 'driver-core-6.11-rc1' of ↵Linus Torvalds3-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the big set of driver core changes for 6.11-rc1. Lots of stuff in here, with not a huge diffstat, but apis are evolving which required lots of files to be touched. Highlights of the changes in here are: - platform remove callback api final fixups (Uwe took many releases to get here, finally!) - Rust bindings for basic firmware apis and initial driver-core interactions. It's not all that useful for a "write a whole driver in rust" type of thing, but the firmware bindings do help out the phy rust drivers, and the driver core bindings give a solid base on which others can start their work. There is still a long way to go here before we have a multitude of rust drivers being added, but it's a great first step. - driver core const api changes. This reached across all bus types, and there are some fix-ups for some not-common bus types that linux-next and 0-day testing shook out. This work is being done to help make the rust bindings more safe, as well as the C code, moving toward the end-goal of allowing us to put driver structures into read-only memory. We aren't there yet, but are getting closer. - minor devres cleanups and fixes found by code inspection - arch_topology minor changes - other minor driver core cleanups All of these have been in linux-next for a very long time with no reported problems" * tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits) ARM: sa1100: make match function take a const pointer sysfs/cpu: Make crash_hotplug attribute world-readable dio: Have dio_bus_match() callback take a const * zorro: make match function take a const pointer driver core: module: make module_[add|remove]_driver take a const * driver core: make driver_find_device() take a const * driver core: make driver_[create|remove]_file take a const * firmware_loader: fix soundness issue in `request_internal` firmware_loader: annotate doctests as `no_run` devres: Correct code style for functions that return a pointer type devres: Initialize an uninitialized struct member devres: Fix memory leakage caused by driver API devm_free_percpu() devres: Fix devm_krealloc() wasting memory driver core: platform: Switch to use kmemdup_array() driver core: have match() callback in struct bus_type take a const * MAINTAINERS: add Rust device abstractions to DRIVER CORE device: rust: improve safety comments MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER firmware: rust: improve safety comments ...
2024-07-22scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONESDamien Le Moal1-2/+18
Some firmware versions of the 9600 series SAS HBA byte-swap the REPORT ZONES command reply buffer from ATA-ZAC devices by directly accessing the buffer in the host memory. This does not respect the default command DMA direction and causes IOMMU page faults on architectures with an IOMMU enforcing write-only mappings for DMA_FROM_DEVICE DMA driection (e.g. AMD hosts). scsi 18:0:0:0: Direct-Access-ZBC ATA WDC WSH722020AL W870 PQ: 0 ANSI: 6 scsi 18:0:0:0: SATA: handle(0x0027), sas_addr(0x300062b2083e7c40), phy(0), device_name(0x5000cca29dc35e11) scsi 18:0:0:0: enclosure logical id (0x300062b208097c40), slot(0) scsi 18:0:0:0: enclosure level(0x0000), connector name( C0.0) scsi 18:0:0:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y) scsi 18:0:0:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1) sd 18:0:0:0: Attached scsi generic sg2 type 20 sd 18:0:0:0: [sdc] Host-managed zoned block device mpt3sas 0000:41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0xfff9b200 flags=0x0050] mpt3sas 0000:41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0xfff9b300 flags=0x0050] mpt3sas_cm0: mpt3sas_ctl_pre_reset_handler: Releasing the trace buffer due to adapter reset. mpt3sas_cm0 fault info from func: mpt3sas_base_make_ioc_ready mpt3sas_cm0: fault_state(0x2666)! mpt3sas_cm0: sending diag reset !! mpt3sas_cm0: diag reset: SUCCESS sd 18:0:0:0: [sdc] REPORT ZONES start lba 0 failed sd 18:0:0:0: [sdc] REPORT ZONES: Result: hostbyte=DID_RESET driverbyte=DRIVER_OK sd 18:0:0:0: [sdc] 0 4096-byte logical blocks: (0 B/0 B) Avoid such issue by always mapping the buffer of REPORT ZONES commands using DMA_BIDIRECTIONAL (read+write IOMMU mapping). This is done by introducing the helper function _base_scsi_dma_map() and using this helper in _base_build_sg_scmd() and _base_build_sg_scmd_ieee() instead of calling directly scsi_dma_map(). Fixes: 471ef9d4e498 ("mpt3sas: Build MPI SGL LIST on GEN2 HBAs and IEEE SGL LIST on GEN3 HBAs") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.