Clang warns (or errors with CONFIG_WERROR=y):
drivers/scsi/dc395x.c:2553:6: error: variable 'id' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
2553 | if (!(rsel_tar_lun_id & (IDENTIFY_BASE << 8)))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/scsi/dc395x.c:2556:22: note: uninitialized use occurs here
2556 | dcb = find_dcb(acb, id, lun);
| ^~
drivers/scsi/dc395x.c:2553:2: note: remove the 'if' if its condition is always true
2553 | if (!(rsel_tar_lun_id & (IDENTIFY_BASE << 8)))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2554 | id = rsel_tar_lun_id & 0xff;
This if statement only existed for a debugging print but it was not
removed with the debugging print in a recent cleanup, leading to id only
being initialized when the if condition is true. Remove the if statement
to ensure id is always initialized, clearing up the warning.
Fixes: 62b434b0db ("scsi: dc395x: Remove DEBUG conditional compilation")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20250429-scsi-dc395x-fix-uninit-var-v1-1-25215d481020@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Mike Christie <michael.christie@oracle.com> says:
The following patches made over Linus's tree remove the atomic use from
the main IO path. There was a handful of atomic_longs used just used
for stats and a couple atomics used for handling ordered commands. These
patches move the stats to per cpu, and moves the ordered tracking to a
per cpu counter.
With the patches 8K IOPS increases by up to 33% when running fio
with numjobs >= 4 and using the vhost-scsi target with virtio-scsi
and virtio num_queues >= 4 (jobs and queues match, and virtqueue_size
and cmd_per_lun are increased to match the total iodepth of all
jobs).
Link: https://lore.kernel.org/r/20250424032741.16216-1-michael.christie@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Don Brace <don.brace@microchip.com> says:
These patches are based on Martin Petersen's 6.16/scsi-queue tree
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
6.16/scsi-queue
There are two main functional changes in this patch series:
smartpqi-take-drives-offline-when-controller-is-offline
smartpqi-fix-smp_processor_id-call-trace-for-preemptible-kernels
The other two patches add PCI-IDs for new controllers and change the
driver version.
This set of changes consists of:
* smartpqi-take-drives-offline-when-controller-is-offline
On rare occasions, the controller can lock up and the driver was
removing the controller instance from OS but leaving the
drives exposed and their state was still 'running'.
This patch sets the drive state as 'offline' to avoid confusion.
* smartpqi-add-new-pci_ids
Add support for more PCI devices.
* smartpqi-enhance_wwid-logging-logic
Cosmetic change for logging WWIDs for NVMe devices and for drives
that support the extended format.
* smartpqi-fix-smp_processor_id-call-trace-for-preemptible-kernels
When preemption is enabled, there are call traces in the console
logs which are annoying. The call trace mentions using
smp_processor_id(). Since the driver is only using this function call
when accessing a per_cpu variable, we changed the call to
raw_smp_processor_id(). This patch was written by
Yi Zhang <yi.zhang@redhat.com> and I am posting it on his behalf.
* smartpqi-update-driver-version-to-2.1.34-035
No functional changes.
Link: https://lore.kernel.org/r/20250423183229.538572-1-don.brace@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Correct kernel call trace when calling smp_processor_id() when called in
preemptible kernels by using raw_smp_processor_id().
smp_processor_id() checks to see if preemption is disabled and if not,
issue an error message followed by a call to dump_stack().
Brief example of call trace:
kernel: check_preemption_disabled: 436 callbacks suppressed
kernel: BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/u1025:0/2354
kernel: caller is pqi_scsi_queue_command+0x183/0x310 [smartpqi]
kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0
kernel: ...
kernel: Workqueue: writeback wb_workfn (flush-253:0)
kernel: Call Trace:
kernel: <TASK>
kernel: dump_stack_lvl+0x34/0x48
kernel: check_preemption_disabled+0xdd/0xe0
kernel: pqi_scsi_queue_command+0x183/0x310 [smartpqi]
kernel: ...
Fixes: 283dcc1b14 ("scsi: smartpqi: add counter for parity write stream requests")
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Tested-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Link: https://lore.kernel.org/r/20250423183229.538572-5-don.brace@microchip.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Justin Tee <justintee8345@gmail.com> says:
Update lpfc to revision 14.4.0.9
This patch set contains fixes related to handling of WQE commands, PCI
function resets, firmware eratta events, ELS retries, a smatch
use-after-free warning, and the creation of a new VMID information entry.
The patches were cut against Martin's 6.16/scsi-queue tree.
Link: https://lore.kernel.org/r/20250425194806.3585-1-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
A failure to unregister with the NVMe transport may occur when a PRLI is
retried.
Remove duplicate testing of NLP_NVME_TARGET flag. Add a secondary check
of the registered state based on the nrport information. Further qualify
the ndlp reference count modification when nvme_fc_register_remoteport()
returns an error.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250425194806.3585-5-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
A PCI function reset implies a temporary disappearance of a fc_rport.
So, call lpfc_scsi_dev_block(), which sets all mapped fc_rports into the
temporary FC_PORTSTATE_BLOCKED state. Once PCI function reset completes
and link reinitialized, the fc_rport is rediscovered and
FC_PORTSTATE_BLOCKED state is removed.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250425194806.3585-3-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In lpfc_check_sli_ndlp(), the get_job_els_rsp64_did remote_id assignment
does not apply for GEN_REQUEST64 commands as it only has meaning for a
ELS_REQUEST64 command. So, if (iocb->ndlp == ndlp) is false, we could
erroneously return the wrong value. Fix by replacing the fallthrough
statement with a break statement before the remote_id check.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20250425194806.3585-2-justintee8345@gmail.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In preparation for making the kmalloc family of allocators type aware, we
need to make sure that the returned type from the allocation matches the
type of the variable being assigned. (Before, the allocator would always
return "void *", which can be implicitly cast to any pointer type.)
The assigned type is "struct crb_addr_pair *" and the returned type will
be a _different_ "struct crb_addr_pair *", causing a warning. This really
stumped me for a bit. :) Drop the redundant declaration.
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250426062010.work.878-kees@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In preparation for making the kmalloc family of allocators type aware, we
need to make sure that the returned type from the allocation matches the
type of the variable being assigned. (Before, the allocator would always
return "void *", which can be implicitly cast to any pointer type.)
The assigned type is "struct crb_addr_pair *" and the returned type will
be a _different_ "struct crb_addr_pair *", causing a warning. This really
stumped me for a bit. :) Drop the redundant declaration.
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250426061951.work.272-kees@kernel.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Pull in fixes from 6.15 and resolve a few conflicts so we can have a
clean base for UFS patches.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
SATA devices are lost when FLR is performed while the controller and disks
are in suspended state.
This is because the libata layer is called to initialize the SATA device
during controller resume. If FLR is executed at this time, the IDENTIFY
command fails. As a result, the revalidate fails, and the SATA device is
disabled by the libata layer.
Wait until error handling completes.
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20250414080845.1220997-5-liyihang9@huawei.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In commit 21c7e97247 ("scsi: hisi_sas: Disable SATA disk phy for severe
I_T nexus reset failure"), if the softreset fails upon certain
conditions, the PHY connected to the disk is disabled directly. Manual
recovery is required, which is inconvenient for users in actual use.
In addition, SATA disks do not support simultaneous connection of multiple
hosts. Therefore, when multiple controllers are connected to a SATA disk
at the same time, the controller which is connected later failed to issue
an ATA softreset to the SATA disk. As a result, the PHY associated with
the disk is disabled and cannot be automatically recovered.
Now that, we will not focus on the execution result of softreset. No
matter whether the execution is successful or not, we will directly carry
out I_T_nexus_reset.
Fixes: 21c7e97247 ("scsi: hisi_sas: Disable SATA disk phy for severe I_T nexus reset failure")
Signed-off-by: Yihang Li <liyihang9@huawei.com>
Link: https://lore.kernel.org/r/20250414080845.1220997-4-liyihang9@huawei.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
