Re: [PATCH v7 15/34] pinctrl: airoha: fix IRQ mask/unmask code

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Adding `gpiochip_enable_irq()` and `gpiochip_disable_irq()` triggers continuous WARN_ON traces and fails to set the IRQ enabled flag due to missing GPIOCHIP_IRQ_RESOURCE_HELPERS.

Pre-existing issues:
- [High] Missing GPIOCHIP_IRQ_RESOURCE_HELPERS causes a module refcount leak, leading to a Use-After-Free panic on module unload.
- [High] The IRQ mask and unmask callbacks call regmap functions that acquire a spinlock_t while a raw_spinlock_t is held, violating lock nesting rules.
--

--- Patch [15]: [PATCH v7 15/34] pinctrl: airoha: fix IRQ mask/unmask code ---
commit f9ea4e1f8ee631522df69bbad30882277aa2e0a4
Author: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

pinctrl: airoha: fix IRQ mask/unmask code

This commit adds gpiochip_enable_irq and gpiochip_disable_irq calls to
the mask and unmask callbacks. This ensures gpiolib correctly tracks when a
pin is actively used as an interrupt.

> diff --git a/drivers/pinctrl/airoha/pinctrl-airoha.c b/drivers/pinctrl/airoha/pinctrl-airoha.c
> index 6b881ab56d9c3..2dc97e0711003 100644
> --- a/drivers/pinctrl/airoha/pinctrl-airoha.c
> +++ b/drivers/pinctrl/airoha/pinctrl-airoha.c
> @@ -2580,6 +2580,7 @@ static void airoha_irq_unmask(struct irq_data *data)
>  	if (WARN_ON_ONCE(data->hwirq >= ARRAY_SIZE(gpiochip->irq_type)))
>  		return;
>  
> +	gpiochip_enable_irq(gc, irqd_to_hwirq(data));

[Severity: High]
Will this trigger a continuous WARN_ON trace and fail to set the flag?

The driver defines airoha_gpio_irq_chip as IRQCHIP_IMMUTABLE but omits the
GPIOCHIP_IRQ_RESOURCE_HELPERS macro. Because of this, .irq_request_resources
is NULL, so the IRQ core bypasses gpiochip_reqres_irq.

Since gpiochip_lock_as_irq is never called, the GPIOD_FLAG_USED_AS_IRQ
bit is never set on the GPIO descriptor.

The newly added gpiochip_enable_irq call has a safety check:

WARN_ON(!test_bit(GPIOD_FLAG_USED_AS_IRQ, &desc->flags));

Because the flag is missing, does this trigger a kernel stack trace on every
mask/unmask operation, completely preventing GPIOD_FLAG_IRQ_IS_ENABLED from
being updated?

[Severity: High]
This is a pre-existing issue, but does the missing
GPIOCHIP_IRQ_RESOURCE_HELPERS macro also cause a module refcount leak?

By bypassing gpiochip_reqres_irq, the try_module_get(gc->gpiodev->owner)
call that pins the GPIO controller module in memory is skipped.

If the pinctrl-airoha module is unloaded while an IRQ is requested, will
subsequent IRQ triggers or unregister operations access freed memory and
cause a use-after-free panic?

[ ... ]

> @@ -2614,6 +2615,7 @@ static void airoha_irq_mask(struct irq_data *data)
>  
>  	regmap_clear_bits(pinctrl->regmap, gpiochip->level[index], mask);
>  	regmap_clear_bits(pinctrl->regmap, gpiochip->edge[index], mask);

[Severity: High]
This is a pre-existing issue, but does calling regmap_clear_bits here
cause a lock nesting violation?

The IRQ core calls the .irq_mask and .irq_unmask callbacks with the irq
descriptor lock held, which is a raw_spinlock_t.

The driver calls regmap_clear_bits and regmap_update_bits on a regmap
that initializes its lock as a spinlock_t. Acquiring a spinlock_t while
holding a raw_spinlock_t is an invalid wait-type nesting violation.

On PREEMPT_RT kernels where spinlock_t is a sleepable rt_mutex, does
acquiring it while holding a raw_spinlock_t result in sleeping in atomic
context?

> +	gpiochip_disable_irq(gc, irqd_to_hwirq(data));
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727074234.3761170-1-mikhail.kshevetskiy@iopsys.eu?part=15