linux-kernel - Re: [PATCH 0/2] gpio: shared: another set of small fixes

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: <CAMRc=McGaZBDQp2+4Q5G_qkKu_fPDxWwsoo3MujkZs70eBDqxQ@mail.gmail.com>
Date: Mon, 5 Jan 2026 08:53:53 -0800
From: Bartosz Golaszewski <brgl@...nel.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, Linus Walleij <linusw@...nel.org>, 
	Bartosz Golaszewski <brgl@...nel.org>, linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] gpio: shared: another set of small fixes

On Mon, 5 Jan 2026 17:48:05 +0100, Marek Szyprowski
<m.szyprowski@...sung.com> said:
> On 05.01.2026 16:52, Bartosz Golaszewski wrote:
>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
>> ---
>> Bartosz Golaszewski (2):
>>        gpio: shared: assign the correct firmware node for reset-gpio use-case
>>        gpio: shared: fix a race condition
>>
>>   drivers/gpio/gpiolib-shared.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>> ---
>> base-commit: 19fb766a1e5ed5943a62fc671c09d45352a81b1d
>> change-id: 20260105-gpio-shared-fixes-40a8ec3b6b25
>
> Those patches indeed fixes some timing issues with the commit
> 49416483a953 ("gpio: shared: allow sharing a reset-gpios pin between
> reset-gpio and gpiolib"), but they also reveals another one. I've
> initially thought that this is a false positive and needs only a proper
> lockdep annotation, but some boards hang just after similar lockdep splat:
>
> ============================================
> WARNING: possible recursive locking detected
> 6.19.0-rc4-next-20260105+ #11974 Not tainted
> --------------------------------------------
> (udev-worker)/192 is trying to acquire lock:
> ffff000004c15098 (&ref->lock){+.+.}-{4:4}, at:
> gpio_shared_dev_is_reset_gpio+0xcc/0x234
>
> but task is already holding lock:
> ffff000004c15898 (&ref->lock){+.+.}-{4:4}, at:
> gpio_shared_add_proxy_lookup+0x98/0x228
>
> other info that might help us debug this:
>   Possible unsafe locking scenario:
>
>         CPU0
>         ----
>    lock(&ref->lock);
>    lock(&ref->lock);
>
>   *** DEADLOCK ***
>
>   May be due to missing lock nesting notation
>
> 3 locks held by (udev-worker)/192:
>   #0: ffff00000b3ad8e8 (&dev->mutex){....}-{4:4}, at:
> __driver_attach+0x90/0x1ac
>   #1: ffff8000830f2600 (gpio_devices_srcu){.+.+}-{0:0}, at:
> gpiod_find_and_request+0x0/0x574
>   #2: ffff000004c15898 (&ref->lock){+.+.}-{4:4}, at:
> gpio_shared_add_proxy_lookup+0x98/0x228
>

Ah this must be due to also trying to compare the ref to the base ref...

Could you try to add the following on top:

diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
index 198951c4c80b..5f3b8bc4a4fc 100644
--- a/drivers/gpio/gpiolib-shared.c
+++ b/drivers/gpio/gpiolib-shared.c
@@ -378,6 +378,9 @@ static bool gpio_shared_dev_is_reset_gpio(struct
device *consumer,
 	 * arguments match the ones from this consumer's node.
 	 */
 	list_for_each_entry(real_ref, &entry->refs, list) {
+		if (real_ref == ref)
+			continue;
+
 		guard(mutex)(&real_ref->lock);

 		if (!real_ref->fwnode)


If that works, I'll send a v2.

Bart