ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter
function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because
resuming involves submitting a SCSI command and ufshcd_queuecommand()
returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this
hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has
been called instead of before.
Backtrace:
__switch_to+0x174/0x338
__schedule+0x600/0x9e4
schedule+0x7c/0xe8
schedule_timeout+0xa4/0x1c8
io_schedule_timeout+0x48/0x70
wait_for_common_io+0xa8/0x160 //waiting on START_STOP
wait_for_completion_io_timeout+0x10/0x20
blk_execute_rq+0xe4/0x1e4
scsi_execute_cmd+0x108/0x244
ufshcd_set_dev_pwr_mode+0xe8/0x250
__ufshcd_wl_resume+0x94/0x354
ufshcd_wl_runtime_resume+0x3c/0x174
scsi_runtime_resume+0x64/0xa4
rpm_resume+0x15c/0xa1c
__pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing
ufshcd_err_handler+0x1a0/0xd08
process_one_work+0x174/0x808
worker_thread+0x15c/0x490
kthread+0xf4/0x1ec
ret_from_fork+0x10/0x20
Signed-off-by: Sanjeev Yadav <sanjeev.y@mediatek.com>
[ bvanassche: rewrote patch description ]
Fixes: 62694735ca ("[SCSI] ufs: Add runtime PM support for UFS host controller driver")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20250523201409.1676055-1-bvanassche@acm.org
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When preparing for UFS clock scaling, the UFS driver will quiesce all
sdevs queues in the UFS SCSI host tagset list and then unquiesce them in
ufshcd_clock_scaling_unprepare(). If the UFS SCSI host async scan is in
progress at this time, some LUs may be added to the tagset list between
UFS clkscale prepare and unprepare. This can cause two issues:
1. During clock scaling, there may be I/O requests issued through new
added queues that have not been quiesced, leading to task abort issue.
2. These new added queues that have not been quiesced will be unquiesced
as well when UFS clkscale is unprepared, resulting in warning prints.
Therefore, use the mutex lock scan_mutex in
ufshcd_clock_scaling_prepare() and ufshcd_clock_scaling_unprepare() to
protect it.
Co-developed-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Can Guo <quic_cang@quicinc.com>
Signed-off-by: Ziqi Chen <quic_ziqichen@quicinc.com>
Link: https://lore.kernel.org/r/20250522081233.2358565-1-quic_ziqichen@quicinc.com
Suggested-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Instances of 'struct target_opcode_descriptor' are not modified in this
driver.
Constifying this structure moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
53602 19750 0 73352 11e88 drivers/target/target_core_spc.o
After:
=====
text data bss dec hex filename
58594 14758 0 73352 11e88 drivers/target/target_core_spc.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/889ee46e75db33e8ab997a627a1d3d651ad648db.1747592774.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
After UFS_ABORT_TASK has been processed successfully, the host will
generate MCQ IRQ for ABORT TAG with response OCS_ABORTED. This results in
ufshcd_compl_one_cqe() calling ufshcd_release_scsi_cmd().
But ufshcd_mcq_abort() already calls ufshcd_release_scsi_cmd(), resulting
in __ufshcd_release() being called twice. This means
hba->clk_gating.active_reqs will be decreased twice, making it go
negative.
Delete ufshcd_release_scsi_cmd() in ufshcd_mcq_abort().
Fixes: f1304d4420 ("scsi: ufs: mcq: Added ufshcd_mcq_abort()")
Signed-off-by: ping.gao <ping.gao@samsung.com>
Link: https://lore.kernel.org/r/20250516083812.3894396-1-ping.gao@samsung.com
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The default device command timeout remains 1.5 seconds, but platform
drivers can override it if needed.
Some UFS device commands may timeout due to being blocked by regular SCSI
write commands. Therefore, the maximum timeout needs to be extended to 30
seconds, matching the SCSI write command timeout. And for error injection
purposes, set the minimum value to 1 ms.
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Link: https://lore.kernel.org/r/20250510080345.595798-1-peter.wang@mediatek.com
Suggested-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
alloc_ordered_workqueue() accepts a format string and format arguments as
part of the call, so there is no need for the indirection of first using
snprintf() to print the name into an local array, and then passing that
array to the allocation call.
Also make the error-/non-error-case handling more canonical in that the
error case is tested in the 'if' that follows the allocation call, and
the default return value of the function is '0'.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: M Nikhil <nikh1092@linux.ibm.com>
Reviewed-by: Nihar Panda <niharp@linux.ibm.com>
Signed-off-by: Nihar Panda <niharp@linux.ibm.com>
Link: https://lore.kernel.org/r/20250507042854.3607038-3-niharp@linux.ibm.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
It is better to print saved_err and saved_uic_err in hex format. Integer
format is hard to decode.
[ 1024.485428] [2: kworker/u20:13:28211] exynos-ufs 17100000.ufs: ufshcd_err_handler started; HBA state eh_fatal; powered 1; shutting down 0; saved_err = 131072; saved_uic_err = 0; force_reset = 0; link is broken
Signed-off-by: Wonkon Kim <wkon.kim@samsung.com>
Link: https://lore.kernel.org/r/20250512025210.5802-1-wkon.kim@samsung.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Having a variable length array at the end of scsi_stream_status_header
only causes problems. Remove it and switch sd_is_perm_stream(), which is
the only place that currently uses it, to use the scsi_stream_status
directly following it in the local buf structure.
Besides being a much better data structure design, this also avoids a
-Wflex-array-member-not-at-end warning.
Reported-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20250505060640.3398500-1-hch@lst.de
Reviewed-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The default atomic write max length in DEF_ATOMIC_WR_MAX_LENGTH is
excessively large.
For 512B LBS, we would get a 4MB max, but due to block layer atomic write
restrictions this is limited to 512KB.
Reduce DEF_ATOMIC_WR_MAX_LENGTH to a value which would be more realistic
(for a real device supporting atomic writes), 64KB.
Signed-off-by: John Garry <john.g.garry@oracle.com>
Link: https://lore.kernel.org/r/20250501100241.930071-1-john.g.garry@oracle.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
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>
