kernel/linux.git/drivers/scsi/aacraid, branch v6.12.80

scsi: aacraid: Stop using PCI_IRQ_AFFINITY

2025-08-20T16:30:48+00:00

[ Upstream commit dafeaf2c03e71255438ffe5a341d94d180e6c88e ] When PCI_IRQ_AFFINITY is set for calling pci_alloc_irq_vectors(), it means interrupts are spread around the available CPUs. It also means that the interrupts become managed, which means that an interrupt is shutdown when all the CPUs in the interrupt affinity mask go offline. Using managed interrupts in this way means that we should ensure that completions should not occur on HW queues where the associated interrupt is shutdown. This is typically achieved by ensuring only CPUs which are online can generate IO completion traffic to the HW queue which they are mapped to (so that they can also serve completion interrupts for that HW queue). The problem in the driver is that a CPU can generate completions to a HW queue whose interrupt may be shutdown, as the CPUs in the HW queue interrupt affinity mask may be offline. This can cause IOs to never complete and hang the system. The driver maintains its own CPU <-> HW queue mapping for submissions, see aac_fib_vector_assign(), but this does not reflect the CPU <-> HW queue interrupt affinity mapping. Commit 9dc704dcc09e ("scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity") tried to remedy this issue may mapping CPUs properly to HW queue interrupts. However this was later reverted in commit c5becf57dd56 ("Revert "scsi: aacraid: Reply queue mapping to CPUs based on IRQ affinity") - it seems that there were other reports of hangs. I guess that this was due to some implementation issue in the original commit or maybe a HW issue. Fix the very original hang by just not using managed interrupts by not setting PCI_IRQ_AFFINITY. In this way, all CPUs will be in each HW queue affinity mask, so should not create completion problems if any CPUs go offline. Signed-off-by: John Garry Link: https://lore.kernel.org/r/20250715111535.499853-1-john.g.garry@oracle.com Closes: https://lore.kernel.org/linux-scsi/20250618192427.3845724-1-jmeneghi@redhat.com/ Reviewed-by: John Meneghini Tested-by: John Meneghini Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

move asm/unaligned.h to linux/unaligned.h

2024-10-02T21:23:23+00:00

asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header. auto-generated by the following: for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2024-09-19T09:28:51+00:00

Pull SCSI updates from James Bottomley: "Updates to the usual drivers (ufs, smartpqi, NCR5380, mac_scsi, lpfc, mpi3mr). There are no user visible core changes and a whole series of minor updates and fixes. The largest core change is probably the simplification of the workqueue allocation path" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (86 commits) scsi: smartpqi: update driver version to 2.1.30-031 scsi: smartpqi: fix volume size updates scsi: smartpqi: fix rare system hang during LUN reset scsi: smartpqi: add new controller PCI IDs scsi: smartpqi: add counter for parity write stream requests scsi: smartpqi: correct stream detection scsi: smartpqi: Add fw log to kdump scsi: bnx2fc: Remove some unused fields in struct bnx2fc_rport scsi: qla2xxx: Remove the unused 'del_list_entry' field in struct fc_port scsi: ufs: core: Remove ufshcd_urgent_bkops() scsi: core: Remove obsoleted declaration for scsi_driverbyte_string() scsi: bnx2i: Remove unused declarations scsi: core: Simplify an alloc_workqueue() invocation scsi: ufs: Simplify alloc*_workqueue() invocation scsi: stex: Simplify an alloc_ordered_workqueue() invocation scsi: scsi_transport_fc: Simplify alloc_workqueue() invocations scsi: snic: Simplify alloc_workqueue() invocations scsi: qedi: Simplify an alloc_workqueue() invocation scsi: qedf: Simplify alloc_workqueue() invocations scsi: myrs: Simplify an alloc_ordered_workqueue() invocation ...

scsi: aacraid: Fix double-free on probe failure

2024-08-23T01:04:12+00:00

aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. Reported-by: Michael Gordon Link: https://bugs.debian.org/1075855 Fixes: 8e0c5ebde82b ("[SCSI] aacraid: Newer adapter communication iterface support") Signed-off-by: Ben Hutchings Link: https://lore.kernel.org/r/ZsZvfqlQMveoL5KQ@decadent.org.uk Signed-off-by: Martin K. Petersen

Merge patch series "scsi: aacraid: struct sgmap: Replace 1-element arrays with flexible arrays"

2024-08-03T01:39:30+00:00

Kees Cook 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/20240711212732.work.162-kees@kernel.org Signed-off-by: Martin K. Petersen

scsi: aacraid: struct {user,}sgmap{,64,raw}: Replace 1-element arrays with flexible arrays

2024-08-03T01:38:08+00:00

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 Link: https://lore.kernel.org/r/20240711215739.208776-2-kees@kernel.org Signed-off-by: Martin K. Petersen

scsi: aacraid: Rearrange order of struct aac_srb_unit

2024-08-03T01:38:08+00:00

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

scsi: aacraid: struct aac_ciss_phys_luns_resp: Replace 1-element array with flexible array

2024-08-03T01:29:09+00:00

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 Link: https://lore.kernel.org/r/20240711175055.work.928-kees@kernel.org Reviewed-by: Gustavo A. R. Silva Reviewed-by: Kees Cook Signed-off-by: Martin K. Petersen

scsi: aacraid: union aac_init: Replace 1-element array with flexible array

2024-08-03T01:28:25+00:00

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 Link: https://lore.kernel.org/r/20240711174815.work.689-kees@kernel.org Reviewed-by: Gustavo A. R. Silva Signed-off-by: Martin K. Petersen

scsi: aacraid: aachba: Replace snprintf() with the safer scnprintf() variant

2024-01-30T01:34:52+00:00

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Adaptec OEM Raid Solutions Cc: PMC-Sierra, Inc Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20240111131732.1815560-6-lee@kernel.org Signed-off-by: Martin K. Petersen