Re: [PATCH 1/2] gpio: sch: use raw_spinlock_t in the irq startup path

[Andy Shevchenko]

On Wed, Jun 17, 2026 at 11:40:34PM +0800, Runyu Xiao wrote:
> sch_irq_unmask() enables the GPIO IRQ and then updates the controller
> state through sch_irq_mask_unmask(), which takes sch->lock with
> spin_lock_irqsave().  The callback can be reached from irq_startup()
> while setting up a requested IRQ.  That path is not sleepable, but on
> PREEMPT_RT a regular spinlock_t becomes a sleeping lock.
> 
> This issue was found by our static analysis tool and then manually
> reviewed against the current tree.
> 
> The grounded PoC kept the request_threaded_irq() -> __setup_irq() ->
> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and
> used the original spin_lock_irqsave(&sch->lock) edge.  Lockdep reported:
> 
>   BUG: sleeping function called from invalid context
>   hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]
>   sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]
>   sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]
>   __setup_irq.constprop.0+0xd/0x30 [vuln_msv]
> 
> Convert the SCH controller lock to raw_spinlock_t.  The same lock is
> also used by the GPIO direction and value callbacks, but those critical
> sections only update MMIO-backed GPIO registers and do not contain
> sleepable operations.  Keeping this register lock non-sleeping is
> therefore appropriate for the irqchip callbacks and does not change the
> GPIO-side locking contract.

Okay, no objection.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>

Bart, you can take it to your branch directly in case it's not too late
for getting into v7.2-rc1, otherwise I can take via my branch and then PR
somewhere near -rc2.

-- 
With Best Regards,
Andy Shevchenko