Re: [PATCH v6 01/13] gpio: mxc: fix race between chained IRQ handler install and probe completion

[Peng Fan <peng.fan@oss.nxp.com>]

On Sun, Oct 11, 2026 at 12:05:47PM +0000, sashiko-bot@kernel.org wrote:
>Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>- [High] gpio: mxc: data race on mxc_gpio_ports list during concurrent probe/interrupt
>--
>
>commit f3eaabd7240ce61fd8c78877e57457bbc5ad25e0
>Author: Peng Fan <peng.fan@nxp.com>
>
>gpio: mxc: fix race between chained IRQ handler install and probe completion
>
>This commit defers chained IRQ handler registration in mxc_gpio_probe() to
>avoid executing the handler before mxc_gpio_ports is updated and other
>probe steps complete.
>
>> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
>> index 7e2690d92df6f..e05f276a50e8d 100644
>> --- a/drivers/gpio/gpio-mxc.c
>> +++ b/drivers/gpio/gpio-mxc.c
>
>[ ... ]
>
>> @@ -525,6 +523,8 @@ static int mxc_gpio_probe(struct platform_device *pdev)
>>  
>>  	list_add_tail(&port->node, &mxc_gpio_ports);
>>  
>> +	mxc_update_irq_chained_handler(port, true);
>> +
>
>[Severity: High]
>Is there a remaining data race here during probe for shared interrupts?

As replied before [1], this is false alarm.

[1] https://lore.kernel.org/all/asg749Hk%2Fhaiis%2Fi@shlinux89/

Regards
Peng

>
>On i.MX21 compatible SoCs, all GPIO ports share the same parent IRQ. When the
>first GPIO port finishes probing, the chained IRQ handler becomes active. 
>
>When the second GPIO port probes, it modifies the global list:
>
>mxc_gpio_probe() {
>    ...
>    list_add_tail(&port->node, &mxc_gpio_ports);
>    ...
>}
>
>If a shared interrupt fires concurrently (either preempting the probe or
>running in parallel), mx2_gpio_irq_handler() traverses this list in hardirq
>context:
>
>mx2_gpio_irq_handler() {
>    ...
>    list_for_each_entry(port, &mxc_gpio_ports, node) {
>        ...
>    }
>}
>
>Since the traversal is done without any synchronization or RCU reader
>protection, and list_add_tail() is called without locks or RCU primitives,
>could the interrupt handler observe partially updated list pointers and
>trigger a kernel panic?
>
>>  	platform_set_drvdata(pdev, port);
>>  	pm_runtime_put_autosuspend(&pdev->dev);
>>
>
>-- 
>Sashiko AI review · https://sashiko.dev/#/patchset/20261011-gpio-mxc-cleanup-v6-0-cb47ce2ad758@nxp.com?part=1
>
>