Re: [PATCH] scsi: ufs: core: Avoid sleeping in hard interrupt context when PREEMP_RT is enabled.

Hello Sebastian,

> On 2026-07-06 07:30:48 [-0700], Bart Van Assche wrote:
>> On 6/30/26 7:15 AM, Sebastian Andrzej Siewior wrote:
>> >  From ufshcd_intr():
>> > |         intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
>> > |         enabled_intr_status = intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);
>> > |
>> > |         ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
>> > 
>> > What does this do? Does it disable the IRQ source? If so then
>> > IRQF_ONESHOT should be removed.
>> 
>> Writing into the REG_INTERRUPT_STATUS register clears the bits that are
>> set in the first argument of writel().
>
> This makes it sounds as it would acknowledge the interrupt. If that is
> the case then there is no need for IRQF_ONESHOT.
>
>> > |         /* Directly handle interrupts since MCQ ESI handlers does the hard job */
>> > |         return ufshcd_sl_intr(hba, enabled_intr_status);
>> > 
>> > If not, why is this not part of the threaded handler?
>> If MCQ is disabled, ufshcd_sl_intr() processes all types of interrupts.
>> If MCQ is enabled, the ESI interrupt handlers process I/O completions
>> and ufshcd_sl_intr() processes the remaining interrupt types.
>
> So MCQ is the trigger. Does its status change after device's init
> time?

The status doesn't change after the device's initialization, so we can
indeed register the interrupt according to whether MCQ is enabled or
not.

>
> If I understood it correctly, after the REG_INTERRUPT_STATUS there is no
> need for IRQF_ONESHOT since this masks the interrupt until the thread is
> done.
>
> If MCQ disabled there is no need for this ACK and the it could be just a
> request_irq(, ufshcd_sl_intr).
>
> If MCQ is enabled then request_threaded_irq(, mask_interrupt_only,
>    ufshcd_threaded_intr, IRQF_NO_THREAD)
>

I'm implementing your solution to see if it fixes the issue without
introducing a regression., but I'm puzzled by this previous line:
`mask_interrupt_only ??`.
Also, I don't understand why `IRQF_NO_THREAD` is used for the threaded
IRQ; it seems to indicate opposite behavior. Could you please explain
what you have in mind ?

Grégory

> Would this work?
>
>> Bart.
>
> Sebastian

-- 
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com