[PATCH v2] ufs: core: Avoid IRQ thread wakeup during active UIC command

[Marek Szyprowski]

Hi Peter,

On 18.03.2026 07:57, Peter Wang (王信友) wrote:
> On Tue, 2026-03-17 at 18:11 +0100, Marek Szyprowski wrote:
>> This patch landed in linux-next as commit 6475cfb81fc4 ("scsi: ufs:
>> core: Avoid IRQ thread wakeup during active UIC command"). In my
>> tests I
>> found that it causes the following regression on QCom RB5 board
>> (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts):
> Hi Marek,
>
> If this issue can always be reproduced with this patch?

The issue I've observed is 100% reproducible. I've checked again by 
compiling the kernel directly from commit 6475cfb81fc4:

=============================
[ BUG: Invalid wait context ]
7.0.0-rc1+ #16536 Not tainted
-----------------------------
swapper/0/0 is trying to lock:
ffff000080bdc048 (shost->host_lock){....}-{3:3}, at: 
ufshcd_sl_intr+0x3c0/0x6b4
other info that might help us debug this:
context-{2:2}
no locks held by swapper/0/0.
stack backtrace:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.0.0-rc1+ #16536 PREEMPT
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
Call trace:
  show_stack+0x18/0x24 (C)
  dump_stack_lvl+0x90/0xd0
  dump_stack+0x18/0x24
  __lock_acquire+0xa40/0x2254
  lock_acquire+0x1c4/0x3fc
  _raw_spin_lock_irqsave+0x60/0x88
  ufshcd_sl_intr+0x3c0/0x6b4
  ufshcd_intr+0x7c/0x90
  __handle_irq_event_percpu+0xa0/0x4c4
  handle_irq_event+0x4c/0xf8
  handle_fasteoi_irq+0x108/0x198
  handle_irq_desc+0x40/0x58
  generic_handle_domain_irq+0x18/0x24
  gic_handle_irq+0x4c/0x110
  call_on_irq_stack+0x30/0x48
  do_interrupt_handler+0x80/0x84
  el1_interrupt+0x3c/0x60
  el1h_64_irq_handler+0x18/0x24
  el1h_64_irq+0x6c/0x70
  cpuidle_enter_state+0xf8/0x41c (P)
  cpuidle_enter+0x38/0x50
  do_idle+0x208/0x290
  cpu_startup_entry+0x34/0x3c
  rest_init+0xf8/0x188
  start_kernel+0x810/0x8e4
  __primary_switched+0x88/0x90
scsi host0: ufshcd



> I have doubts because, in your log, it seems to be ISR trying
> to acquire the spinlock (shost->host_lock), but cannot obtain
> it in time, causing a timeout.
>
> ufshcd-qcom 1d84000.ufshc: uic cmd 0x1 with arg3 0x0 completion timeout
> ufshcd-qcom 1d84000.ufshc: dme-get: sttr-id 0x41 failed 0 retries no
> locks held by swapper/0/0.
> ufshcd-qcom 1d84000.ufshc: ufs_wcom_check_hibern8: unable to get
> TX_FSM_STATE, err -110 stack backtrace:
> ufshcd-qcom 1d84000.ufshc: No active UIC command. Maybe a timeout
> occurred?
> ufshcd-qcom 1d84000.ufshc: ufshcd_threaded_intr: Unhadled interrupt
> 0x00000000 (0x00000400, 0x00000400)
>
> Regardless of whether it runs in IRQ or thread IRQ context, the
> outcome is the same (host_lock cannot be acquired in time).
> So, could you check why this spinlock cannot be acquired first?
> Additionally, ufs_wcom_check_hibern8 does not appear in the
> current code base, so there might be some other unknown code
> that has already acquired host_lock in your code base?

You have probably mixed my report with this one 
https://lore.kernel.org/all/abmNkRC_vSVaP2sC@mail.iam.tj/

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland