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

[Marek Szyprowski]

On 18.03.2026 18:32, Bart Van Assche wrote:
> On 3/18/26 10:13 AM, Marek Szyprowski wrote:
>> On 18.03.2026 16:50, Bart Van Assche wrote:
>>> On 3/17/26 10:11 AM, 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):
>>>>
>>>> =============================
>>>> [ BUG: Invalid wait context ]
>>>> 7.0.0-rc4-next-20260316 #16535 Not tainted
>>>> -----------------------------
>>>> swapper/0/0 is trying to lock:
>>>> ffff000089f58048 (shost->host_lock){....}-{3:3}, at:
>>>
>>> This line is a mystery to me. Are there perhaps any local changes in
>>> your kernel tree on top of linux-next? I haven't been able to find the
>>> text "shost->host_lock" in the UIC completion path.
>>
>> I don't have any local changes, code is at commit 6475cfb81fc4. After
>> looking at the code this 'shost' indeed looks a bit mysterious, but
>> maybe it got that name after some inlining or code optimization.
>>
>>> Instead, this is
>>> what I found:
>>>
>>>      guard(spinlock_irqsave)(hba->host->host_lock);
>>>
>>>> ufshcd_sl_intr+0x3c0/0x6b4
>>>
>>> Can you please help with translating this information into a line
>>> number? Tools like addr2line, llvm-addr2line or llvm-objdump -d -l -S
>>> can be used to perform such a conversion.
>>
>> ufshcd_clk_scaling_allow() in drivers/ufs/core/ufshcd.c:6492 (code
>> checkout at git commit 6475cfb81fc4)
>
> Hi Marek,
>
> I haven't been able to find any call chain from ufshcd_sl_intr() into
> ufshcd_clk_scaling_allow(). Am I perhaps overlooking something?

I must have mixed something while calculating offsets for addr2line. I 
checked again and I found that there is already a script doing that. 
I've recompiled kernel with -Os (assuming that this way less code will 
be inlined) and this is the result:

=============================
[ BUG: Invalid wait context ]
7.0.0-rc1+ #16537 Not tainted
-----------------------------
swapper/0/0 is trying to lock:
ffff000080a04048 (shost->host_lock){....}-{3:3}, at: 
ufshcd_sl_intr+0x50/0x598
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+ #16537 PREEMPT
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
Call trace:
  show_stack+0x18/0x24 (C)
  dump_stack_lvl+0x6c/0x94
  dump_stack+0x18/0x24
  __lock_acquire+0x3f8/0x10ac
  lock_acquire+0x29c/0x2ec
  _raw_spin_lock_irqsave+0x58/0x78
  ufshcd_sl_intr+0x50/0x598
  ufshcd_intr+0x64/0x78
  __handle_irq_event_percpu+0x1d4/0x354
  handle_irq_event_percpu+0x18/0x4c
  handle_irq_event+0x48/0x90
  handle_fasteoi_irq+0xc4/0xe8
  handle_irq_desc+0x48/0x58
  generic_handle_domain_irq+0x18/0x24
  gic_handle_irq+0xa4/0x108
  call_on_irq_stack+0x30/0x48
  do_interrupt_handler+0x88/0x94
  el1_interrupt+0x3c/0x60
  el1h_64_irq_handler+0x18/0x24
  el1h_64_irq+0x6c/0x70
  cpuidle_enter_state+0x1c0/0x2f0 (P)
  cpuidle_enter+0x38/0x50
  do_idle+0x23c/0x260
  cpu_startup_entry+0x34/0x38
  kernel_init+0x0/0x12c
  start_kernel+0x7e4/0x7f0
  __primary_switched+0x88/0x90


# ./scripts/faddr2line vmlinux "ufshcd_sl_intr+0x50/0x598"
ufshcd_sl_intr+0x50/0x598:
ufshcd_uic_cmd_compl at drivers/ufs/core/ufshcd.c:5570
(inlined by) ufshcd_sl_intr at drivers/ufs/core/ufshcd.c:7144


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