linux-kernel - RE: [PATCH v2] pinctrl: renesas: rzt2h: fix invalid wait context

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <TYRPR01MB1561934DB60CE0C07D39264D78599A@TYRPR01MB15619.jpnprd01.prod.outlook.com>
Date: Thu, 5 Feb 2026 14:30:36 +0000
From: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC: Geert Uytterhoeven <geert+renesas@...der.be>, Linus Walleij
	<linusw@...nel.org>, Clark Williams <clrkwllms@...nel.org>, Steven Rostedt
	<rostedt@...dmis.org>, Bartosz Golaszewski <brgl@...nel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-rt-devel@...ts.linux.dev" <linux-rt-devel@...ts.linux.dev>
Subject: RE: [PATCH v2] pinctrl: renesas: rzt2h: fix invalid wait context

> From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> Sent: Thursday, February 5, 2026 2:05 PM
> 
> On 2026-02-05 12:39:30 [+0200], Cosmin Tanislav wrote:
> > The rzt2h_gpio_get_direction() function is called from
> > gpiod_get_direction(), which ends up being used within the __setup_irq()
> > call stack when requesting an interrupt.
> >
> > __setup_irq() holds a raw_spinlock_t with IRQs disabled, which creates
> > an atomic context. spinlock_t cannot be used within atomic context
> > when PREEMPT_RT is enabled, since it may become a sleeping lock.
> >
> > An "[ BUG: Invalid wait context ]" splat is observed when running with
> > CONFIG_PROVE_LOCKING enabled, describing exactly the aforementioned call
> > stack.
> >
> > __setup_irq() needs to hold a raw_spinlock_t with IRQs disabled to
> > serialize access against a concurrent hard interrupt.
> >
> > Switch to raw_spinlock_t to fix this.
> 
> I don't like the reasoning here because it looks like "lockdep
> complained lets switch the locks and everything is fine now".
> 
> It is required to make the suggested change because the lock is used
> in hardirq context and only while accessing the HW's register.
> 
> I just don't want that a lockdep splat becomes a green card for these
> kind of changes without understanding the consequences.
> 

Hi Sebastian, thank you for your feedback.

I agree that a lockdep splat should not warrant a spinlock_t to
raw_spinlock_t conversion since that's not always the correct solution
for it.

This driver delegates masking/unmasking to the parent IRQ chip, and none
of the local irq_chip callbacks take the pctrl->lock.

The pctrl->lock is taken in the gpio_chip->request, ->get_direction,
->direction_input, ->direction_output, pinmux_ops->set_mux and
gpio_irq_chip->child_to_parent_hwirq implementations.

My understanding is that the only issue is that ->get_direction takes a
spinlock_t while being called from __setup_irq() which holds a
raw_spinlock_t with IRQs disabled, rather than spinlock_t being taken
inside a hardirq context, which is what I tried to describe in the
commit message.

Am I missing something?

> > Fixes: 829dde3369a9 ("pinctrl: renesas: rzt2h: Add GPIO IRQ chip to handle interrupts")
> > Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
> 
> Sebastian