linux-kernel - Re: 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] [day] [month] [year] [list]

Message-ID: <20260205160041.TIoBDYAk@linutronix.de>
Date: Thu, 5 Feb 2026 17:00:41 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Cosmin-Gabriel Tanislav <cosmin-gabriel.tanislav.xa@...esas.com>
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: RE: [PATCH v2] pinctrl: renesas: rzt2h: fix invalid wait context

On 2026-02-05 14:30:36 [+0000], Cosmin-Gabriel Tanislav wrote:
> 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?

I see. Usually there is also mask/ unmask which makes this mandatory for
this as well. In that case it is probably just the invocation from
__setup(). Instead of nitpicking here 

Reviewed-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>

and you said that the splat does warrant for the lock splat so I hope
the best ;)

Sebastian