linux-stable.git/drivers/ufs/core, branch master

ufs: core: tracing: Do not dereference pointers in TP_printk()

2026-07-07T14:42:28+00:00

The trace events in drivers/ufs/core/ufs_trace.h were converted to take a
pointer to the hba structure as an argument for the tracepoint and then in
TP_printk() the printing of the dev_name from the ring buffer was
converted to using the dev dereferenced pointer from the hba saved
pointer.

This is not allowed as the TP_printk() is executed at the time the trace
event is read from /sys/kernel/tracing/trace file. That can happen
literally, seconds, minutes, hours, weeks, days, or even months later!
There is no guarantee that the hba pointer will still exist by the time it
is dereferenced when the "trace" file is read.

Instead, save the device name from the hba pointer at the time the
tracepoint is called and place it into the ring buffer event. Then the
TP_printk() can read the name directly from the ring buffer and remove the
possibility that it will read a freed pointer and crash the kernel.

This was detected when testing the trace event code that looks for
TP_printk() parameters doing illegal derferences[1]

[1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260630185412.283c26c5@gandalf.local.home
Fixes: 583e518e71003 ("scsi: ufs: core: Add hba parameter to trace events")
Reviewed-by: Peter Wang 
Reviewed-by: Bart Van Assche 
Signed-off-by: Steven Rostedt

Merge branch 7.1/scsi-fixes into 7.2/scsi-staging

2026-06-16T01:01:30+00:00

Pull in outstanding commits from 7.1 branch.

Signed-off-by: Martin K. Petersen

scsi: ufs: core: Handle PM commands timeout before SCSI EH

2026-06-08T21:41:45+00:00

A PM START STOP sent from the UFS well-known LU resume path can race
with SCSI EH:

The "wl resume" task flow is:
  __ufshcd_wl_resume()
    ufshcd_set_dev_pwr_mode(UFS_ACTIVE_PWR_MODE)
      ufshcd_execute_start_stop()
        scsi_execute_cmd()
          blk_execute_rq           <-- wait
          scsi_check_passthrough() <-- may retry START STOP

If the first START STOP time out, SCSI EH may already recover the link and
reset the device before scsi_execute_cmd() returns:

  scsi_timeout()
    scsi_eh_scmd_add()
      scsi_error_handler()
        scsi_unjam_host()
          scsi_eh_ready_devs()
            scsi_eh_host_reset()
              ufshcd_eh_host_reset_handler()
                if (hba->pm_op_in_progress)
                  ufshcd_link_recovery()
                    ufshcd_device_reset()
                    ufshcd_host_reset_and_restore()
          ...
          scsi_eh_flush_done_q()   <-- wakeup "wl resume" task
        ...                        <-- host still in SHOST_RECOVERY
        scsi_restart_operations()

A later passthrough retry can then run while the host is still in
SHOST_RECOVERY and hit the SCMD_FAIL_IF_RECOVERING path:

  scsi_queue_rq()
    if (scsi_host_in_recovery(shost) &&
        cmd->flags & SCMD_FAIL_IF_RECOVERING)
      return BLK_STS_OFFLINE

That retry completes with DID_ERROR or DID_NO_CONNECT even though EH may
already have restored the device to an operational ACTIVE state.

Handle these PM timeouts directly from ufshcd_eh_timed_out() instead.
After ufshcd_link_recovery(), complete the timed-out command immediately
if it has not been completed already.

For regular SCSI commands, complete them with DID_REQUEUE to match the
existing MCQ force-completion semantics and allow scsi_execute_cmd() to
retry if needed. For reserved internal device-management commands,
finish the request with DID_TIME_OUT without calling
ufshcd_release_scsi_cmd() since those commands use different resource
lifetime rules.

The system_suspending flag is no longer needed because PM command
timeout handling now uses pm_op_in_progress.

Fixes: b8c3a7bac9b6 ("scsi: ufs: Have midlayer retry start stop errors")
Signed-off-by: Hongjie Fang 
Reviewed-by: Bart Van Assche 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260605112034.3802540-1-hongjiefang@asrmicro.com
Signed-off-by: Martin K. Petersen

scsi: ufs: Remove redundant vops NULL check and trivial wrapper

2026-06-02T02:01:54+00:00

ufshcd_variant_hba_init/exit() check 'if (!hba->vops)' before calling
vops wrappers, but the wrappers already do NULL check internally. Remove
the redundant checks. Also remove ufshcd_variant_hba_exit() entirely
since it only wraps ufshcd_vops_exit() with no added value.

Signed-off-by: Chanwoo Lee 
Reviewed-by: Peter Wang 
Reviewed-by: Bart Van Assche 
Link: https://patch.msgid.link/20260529061623.301291-1-cw9316.lee@samsung.com
Signed-off-by: Martin K. Petersen

scsi: ufs: Remove unnecessary return in void vops wrappers

2026-06-02T01:59:51+00:00

ufshcd_vops_exit(), ufshcd_vops_setup_task_mgmt(), and
ufshcd_vops_hibern8_notify() use 'return hba->vops->xxx()' while other
void vops wrappers call without return.  Remove the unnecessary return
keywords for consistency.

Signed-off-by: Chanwoo Lee 
Reviewed-by: Peter Wang 
Reviewed-by: Bart Van Assche 
Link: https://patch.msgid.link/20260529061503.301182-1-cw9316.lee@samsung.com
Signed-off-by: Martin K. Petersen

scsi: ufs: Fix wrong value printed in unexpected UPIU response case

2026-06-02T01:59:00+00:00

In ufshcd_transfer_rsp_status(), the default case of the inner switch
statement prints the UPIU response code when an unexpected response is
received. However, the code was printing 'result' variable which is
always 0 at that point, making the error message useless for debugging.

Fix this by printing the actual UPIU response code returned by
ufshcd_get_req_rsp().

Fixes: 08108d31129a ("scsi: ufs: Improve type safety")
Signed-off-by: Chanwoo Lee 
Reviewed-by: Bart Van Assche 
Link: https://patch.msgid.link/20260527092134.275887-1-cw9316.lee@samsung.com
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Fix NULL pointer dereference in scsi_cmd_priv() calls

2026-06-02T01:57:52+00:00

ufshcd_tag_to_cmd() may return NULL if no command is associated with the
given tag. However, several callers dereference the returned cmd pointer
via scsi_cmd_priv() without checking for NULL first, leading to a
potential NULL pointer dereference.

Fix this by adding NULL checks for cmd before calling scsi_cmd_priv()
and moving the lrbp initialization after the NULL check.

Signed-off-by: Chanwoo Lee 
Reviewed-by: Peter Wang 
Reviewed-by: Bart Van Assche 
Link: https://patch.msgid.link/20260529010739.295391-1-cw9316.lee@samsung.com
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Skip link param validation when lanes_per_direction is unset

2026-06-02T01:44:21+00:00

ufshcd_validate_link_params(), added by commit e72323f3b09f ("scsi: ufs:
core: Configure only active lanes during link"), is called
unconditionally from ufshcd_link_startup() and fails link startup with
-ENOLINK when the connected lane count read from the device differs from
hba->lanes_per_direction.

lanes_per_direction is only set by ufshcd-pltfrm (default 2, or the
"lanes-per-direction" devicetree property); ufshcd-pci controllers
(e.g. Intel) leave it 0. As the device always reports >= 1 connected
lanes, the check can never match and link startup always fails.
Reproduced with QEMU's UFS device.

Skip the check when lanes_per_direction is unset: with no expected value
to validate against, restore the behaviour from before that commit.

Fixes: e72323f3b09f ("scsi: ufs: core: Configure only active lanes during link")
Signed-off-by: Daejun Park 
Reviewed-by: Bart Van Assche 
Reviewed-by: Manivannan Sadhasivam 
Link: https://patch.msgid.link/20260520070009epcms2p6542f3abb7660839e9d8140b3f2f145c3@epcms2p6
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Optimize ufshcd_add_uic_command_trace()

2026-05-23T01:40:40+00:00

Use cached values in ufshcd_add_uic_command_trace() instead of calling
readl() when tracing command submission (UFS_CMD_SEND).

Signed-off-by: Bart Van Assche 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260519212135.3130556-4-bvanassche@acm.org
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Complain if UIC argument 2 is invalid

2026-05-23T01:40:39+00:00

According to the UFSHCI standard, the lowest byte of UIC argument 2 is
an output value. Additionally, ufshcd_uic_cmd_compl() is based on the
assumption that the lowest byte of UIC argument 2 is zero. Hence,
complain if the result byte is set when a UIC command is submitted.

Reviewed-by: Peter Wang 
Signed-off-by: Bart Van Assche 
Link: https://patch.msgid.link/20260519212135.3130556-3-bvanassche@acm.org
Signed-off-by: Martin K. Petersen