| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CANAwSgSjCm+mXxdH5jgN==zfHSvFASxOy4dQkhhLs6hrXAtf-w@mail.gmail.com>
Date: Thu, 8 Jan 2026 12:25:52 +0530
From: Anand Moon <linux.amoon@...il.com>
To: Hans de Goede <hansg@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sebastian Reichel <sebastian.reichel@...labora.com>, FUKAUMI Naoki <naoki@...xa.com>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>,
Cristian Ciocaltea <cristian.ciocaltea@...labora.com>, Yongbo Zhang <giraffesnn123@...il.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>,
"moderated list:ARM/Rockchip SoC support" <linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC support" <linux-rockchip@...ts.infradead.org>,
open list <linux-kernel@...r.kernel.org>,
"open list:USB TYPEC CLASS" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v1 3/3] usb: typec: fusb302: Switch to threaded interrupt handler
Hi Hans De,
Thanks for your review comments.
On Sat, 3 Jan 2026 at 17:32, Hans de Goede <hansg@...nel.org> wrote:
>
> Hi,
>
> On 3-Jan-26 09:31, Anand Moon wrote:
> > The fusb302 driver triggers a "BUG: Invalid wait context" lockdep warning
> > under certain configurations (such as when CONFIG_PROVE_RAW_LOCK_NESTING
> > is enabled). This occurs because the interrupt handler, fusb302_irq_intn,
> > attempts to acquire a regular spinlock (&chip->irq_lock) while running
> > in hardirq context can lead to invalid wait context reports if the lock is
> > considered "sleepable" or has incompatible nesting levels with the
> > underlying interrupt controller's locks.
> >
> > lockdep warnings:
> >
> > [ 38.935276] [ C0] =============================
> > [ 38.935690] [ C0] [ BUG: Invalid wait context ]
> > [ 38.936106] [ C0] 6.19.0-rc2-2-ARM64-GCC #2 Tainted: GT
> > [ 38.936716] [ C0] -----------------------------
> > [ 38.937129] [ C0] kworker/0:0/8 is trying to lock:
> > [ 38.937566] [ C0] ffff000112c04190 (&chip->irq_lock){....}-{3:3}, at: fusb302_irq_intn+0x38/0x98 [fusb302]
> > [ 38.938450] [ C0] other info that might help us debug this:
> > [ 38.938953] [ C0] context-{2:2}
> > [ 38.939247] [ C0] 2 locks held by kworker/0:0/8:
> > [ 38.939670] [ C0] #0: ffff000100025148 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x224/0x4b8
> > [ 38.940645] [ C0] #1: ffff8000800fbd90 ((work_completion)(&(&host->detect)->work)){+.+.}-{0:0}, at: process_one_work+0x24c/0x4b8
> > [ 38.941691] [ C0] stack backtrace:
> > [ 38.942010] [ C0] CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Tainted: GT 6.19.0-rc2-2-ARM64-GCC #2 PREEMPT(full) bd73c5afc1bd41f04ef9699c14f0381f835f4deb
> > [ 38.942017] [ C0] Tainted: [T]=RANDSTRUCT
> > [ 38.942019] [ C0] Hardware name: Radxa ROCK 5B (DT)
> > [ 38.942022] [ C0] Workqueue: events_freezable mmc_rescan
> > [ 38.942031] [ C0] Call trace:
> > [ 38.942033] [ C0] show_stack+0x24/0x40 (C)
> > [ 38.942041] [ C0] dump_stack_lvl+0x90/0xd8
> > [ 38.942047] [ C0] dump_stack+0x1c/0x3c
> > [ 38.942051] [ C0] __lock_acquire+0x5e8/0x9c8
> > [ 38.942059] [ C0] lock_acquire+0x134/0x280
> > [ 38.942065] [ C0] _raw_spin_lock_irqsave+0x80/0xb0
> > [ 38.942072] [ C0] fusb302_irq_intn+0x38/0x98 [fusb302 634bac905a09c450b54f88b96019accd2820228f]
> > [ 38.942082] [ C0] __handle_irq_event_percpu+0x138/0x3f0
> > [ 38.942088] [ C0] handle_irq_event+0x58/0xd8
> > [ 38.942093] [ C0] handle_level_irq+0x108/0x190
> > [ 38.942099] [ C0] handle_irq_desc+0x4c/0x78
> > [ 38.942106] [ C0] generic_handle_domain_irq+0x24/0x40
> > [ 38.942113] [ C0] rockchip_irq_demux+0x128/0x240
> > [ 38.942120] [ C0] handle_irq_desc+0x4c/0x78
> > [ 38.942127] [ C0] generic_handle_domain_irq+0x24/0x40
> > [ 38.942133] [ C0] __gic_handle_irq_from_irqson.isra.0+0x260/0x370
> > [ 38.942141] [ C0] gic_handle_irq+0x68/0xa0
> > [ 38.942146] [ C0] call_on_irq_stack+0x48/0x68
> > [ 38.942152] [ C0] do_interrupt_handler+0x74/0x98
> > [ 38.942158] [ C0] el1_interrupt+0x88/0xb0
> > [ 38.942165] [ C0] el1h_64_irq_handler+0x1c/0x30
> > [ 38.942170] [ C0] el1h_64_irq+0x84/0x88
> > [ 38.942175] [ C0] arch_counter_get_cntpct+0x4/0x20 (P)
> > [ 38.942181] [ C0] __const_udelay+0x30/0x48
> > [ 38.942187] [ C0] mci_send_cmd.constprop.0+0x84/0xc8
> > [ 38.942194] [ C0] dw_mci_setup_bus+0x60/0x210
> > [ 38.942200] [ C0] dw_mci_set_ios+0x1c8/0x260
> > [ 38.942206] [ C0] mmc_set_initial_state+0x110/0x140
> > [ 38.942211] [ C0] mmc_rescan_try_freq+0x154/0x198
> > [ 38.942216] [ C0] mmc_rescan+0x1cc/0x278
> > [ 38.942221] [ C0] process_one_work+0x284/0x4b8
> > [ 38.942225] [ C0] worker_thread+0x264/0x3a0
> > [ 38.942230] [ C0] kthread+0x11c/0x138
> > [ 38.942236] [ C0] ret_from_fork+0x10/0x20
> > [ 38.969307] [ T11] rockchip-dw-pcie a41000000.pcie: PCI host bridge to bus 0004:40
> > [ 38.969995] [ T11] pci_bus 0004:40: root bus resource [bus 40-4f]
> >
> > Following changes resolves the lockdep warnings and aligns the driver with best
> > practices for I2C-based interrupt handling.
> >
> > Cc: Hans de Goede <hansg@...nel.org>
> > Cc: Yongbo Zhang <giraffesnn123@...il.com>
> > Cc: Sebastian Reichel <sebastian.reichel@...labora.com>
> > Fixes: 309b6341d557 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
> > Signed-off-by: Anand Moon <linux.amoon@...il.com>
>
> If you look closer at the code then you will see that
> fusb302_irq_intn() is effectively doing its own threaded
> interrupt handling this is done to be able to delay
> the threaded part till after the i2c-controller is
> resumed when a fusb302 irq wakes up the system.
>
> See commit 207338ec5a27 ("usb: typec: fusb302: Improve
> suspend/resume handling") for details.
>
> And if you look at the fusb302 git history then you'll
> seen an earlier change the switch the interrupt handler
> to a threaded IRQ which was reverted (mostly due to it
> also making other undesirable changes).
>
Yes, I have gone through the change logs
> This change is different though. This is actually quite
> similar to commit cee3dba7b741 ("mei: vsc: Fix "BUG: Invalid
> wait context" lockdep error"). Where I fixed more or less
> the same issue in the same way. So I guess this change also
> is ok.
Yes, ideally, all the CPU cores should handle the IRQ.
alarm@...kpi-5b:~$ cat /proc/interrupts | grep fsc_interrupt_int_n
59: 15 0 0 0 0 0
0 0 rockchip_gpio_irq 12 Level
fsc_interrupt_int_n
>
> Still ideally we would solve this in another way then
> switching to a threaded IRQ handler.
I don't know but this could be related to
>
> As the commit message of the mei-vsc fix mentions
> the root cause of these errors is typically an interrupt
> chip driver which uses IRQF_NO_THREAD disabling the auto
> threading of all interrupt handlers in RT mode.
>
> So the first question here would be to see if that flag is
> used in the interrupt chip and if yes, is that flag really
> necessary ?
No, I did not find this IRQF_NO_THREAD flag being used by Rockchip SoC
i2c
[1] https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-rk3x.c#L1310-L1325
gpio
[2] https://github.com/torvalds/linux/blob/master/drivers/gpio/gpio-rockchip.c#L520-L582
pinctrl
[3] https://github.com/torvalds/linux/blob/master/drivers/pinctrl/pinctrl-rockchip.c
pinctrl power management IC
[4] https://github.com/torvalds/linux/blob/master/drivers/pinctrl/pinctrl-rk805.c
>
> Regards,
>
> Hans
Thnaks
-Anand
Powered by blists - more mailing lists