user/sven/linux.git/drivers/scsi, branch v6.10.14

scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers

2024-10-10T10:00:36Z

[ Upstream commit 1c71065df2df693d208dd32758171c1dece66341 ] 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 Signed-off-by: Finn Thain Link: https://lore.kernel.org/r/52e02a8812ae1a2d810d7f9f7fd800c3ccc320c4.1723001788.git.fthain@linux-m68k.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Update PRLO handling in direct attached topology

2024-10-10T10:00:36Z

[ Upstream commit 1f0f7679ad8942f810b0f19ee9cf098c3502d66a ] 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 Link: https://lore.kernel.org/r/20240726231512.92867-7-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached topology

2024-10-10T10:00:36Z

[ Upstream commit b5c18c9dd138733c16893613345af44deadcf05e ] 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 Link: https://lore.kernel.org/r/20240726231512.92867-6-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths

2024-10-10T10:00:35Z

[ Upstream commit 2be1d4f11944cd6283cb97268b3e17c4424945ca ] 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 Link: https://lore.kernel.org/r/20240726231512.92867-4-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: aacraid: Rearrange order of struct aac_srb_unit

2024-10-10T10:00:35Z

[ Upstream commit 6e5860b0ad4934baee8c7a202c02033b2631bb44 ] 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 Link: https://lore.kernel.org/r/20240711215739.208776-1-kees@kernel.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: smartpqi: add new controller PCI IDs

2024-10-10T10:00:32Z

[ Upstream commit dbc39b84540f746cc814e69b21e53e6d3e12329a ] All PCI ID entries in Hex. Add new cisco pci ids: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 028f 1137 02fe 9005 028f 1137 02ff 9005 028f 1137 0300 Add new h3c pci ids: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 028f 193d 0462 9005 028f 193d 8462 Add new ieit pci ids: VID / DID / SVID / SDID ---- ---- ---- ---- 9005 028f 1ff9 00a3 Reviewed-by: Scott Benesh Reviewed-by: Mike McGowen Signed-off-by: David Strahan Signed-off-by: Don Brace Link: https://lore.kernel.org/r/20240827185501.692804-5-don.brace@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: smartpqi: correct stream detection

2024-10-10T10:00:32Z

[ Upstream commit 4c76114932d1d6fad2e72823e7898a3c960cf2a7 ] Correct stream detection by initializing the structure pqi_scsi_dev_raid_map_data to 0s. When the OS issues SCSI READ commands, the driver erroneously considers them as SCSI WRITES. If they are identified as sequential IOs, the driver then submits those requests via the RAID path instead of the AIO path. The 'is_write' flag might be set for SCSI READ commands also. The driver may interpret SCSI READ commands as SCSI WRITE commands, resulting in IOs being submitted through the RAID path. Note: This does not cause data corruption. Reviewed-by: Scott Benesh Reviewed-by: Scott Teel Reviewed-by: Mike McGowen Signed-off-by: Mahesh Rajashekhara Signed-off-by: Don Brace Link: https://lore.kernel.org/r/20240827185501.692804-3-don.brace@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: smartpqi: Add new controller PCI IDs

2024-10-10T10:00:30Z

[ Upstream commit 0e21e73384d324f75ea16f3d622cfc433fa6209b ] 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 Reviewed-by: Scott Teel Reviewed-by: Mike McGowen Signed-off-by: David Strahan Signed-off-by: Don Brace Link: https://lore.kernel.org/r/20240711194704.982400-2-don.brace@microchip.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: pm8001: Do not overwrite PCI queue mapping

2024-10-10T10:00:03Z

[ Upstream commit a141c17a543332fc1238eb5cba562bfc66879126 ] blk_mq_pci_map_queues() maps all queues but right after this, we overwrite these mappings by calling blk_mq_map_queues(). Just use one helper but not both. Fixes: 42f22fe36d51 ("scsi: pm8001: Expose hardware queues for pm80xx") Reviewed-by: Christoph Hellwig Reviewed-by: John Garry Signed-off-by: Daniel Wagner Link: https://lore.kernel.org/r/20240912-do-not-overwrite-pci-mapping-v1-1-85724b6cec49@suse.de Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: st: Fix input/output error on empty drive reset

2024-10-10T10:00:02Z

[ Upstream commit 3d882cca73be830549833517ddccb3ac4668c04e ] A previous change was introduced to prevent data loss during a power-on reset when a tape is present inside the drive. This commit set the "pos_unknown" flag to true to avoid operations that could compromise data by performing actions from an untracked position. The relevant change is commit 9604eea5bd3a ("scsi: st: Add third party poweron reset handling") As a consequence of this change, a new issue has surfaced: the driver now returns an "Input/output error" even for empty drives when the drive, host, or bus is reset. This issue stems from the "flush_buffer" function, which first checks whether the "pos_unknown" flag is set. If the flag is set, the user will encounter an "Input/output error" until the tape position is known again. This behavior differs from the previous implementation, where empty drives were not affected at system start up time, allowing tape software to send commands to the driver to retrieve the drive's status and other information. The current behavior prioritizes the "pos_unknown" flag over the "ST_NO_TAPE" status, leading to issues for software that detects drives during system startup. This software will receive an "Input/output error" until a tape is loaded and its position is known. To resolve this, the "ST_NO_TAPE" status should take priority when the drive is empty, allowing communication with the drive following a power-on reset. At the same time, the change should continue to protect data by maintaining the "pos_unknown" flag when the drive contains a tape and its position is unknown. Signed-off-by: Rafael Rocha Link: https://lore.kernel.org/r/20240905173921.10944-1-rrochavi@fnal.gov Fixes: 9604eea5bd3a ("scsi: st: Add third party poweron reset handling") Acked-by: Kai Mäkisara Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin