linux-kernel - Re: [6.19-rc2 arm64] sleeping while atomic in gpiod_configure

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: <CAMVG2suxTXHL+d3Cd_u1w5taWKfG=1C6BVhpXgPNs58VzS88Uw@mail.gmail.com>
Date: Sun, 4 Jan 2026 13:48:57 +0800
From: Daniel J Blueman <daniel@...ra.org>
To: Bartosz Golaszewski <brgl@...nel.org>
Cc: Linus Walleij <linusw@...nel.org>, linux-gpio@...r.kernel.org, 
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [6.19-rc2 arm64] sleeping while atomic in gpiod_configure_flags

On Fri, 2 Jan 2026 at 16:49, Bartosz Golaszewski <brgl@...nel.org> wrote:
>
> On Sun, Dec 28, 2025 at 8:18 AM Daniel J Blueman <daniel@...ra.org> wrote:
> >
> > Hi Linus, Bartosz et al,
> >
> > When booting 6.19-rc2 [1, 2] with lockdep enabled on a Qualcomm X1
> > Lenovo Slim7x ARM64 laptop, I am seeing mutex usage while atomic
> > during gpiod driver registration:
> >
> > BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
> > in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 170, name: kworker/u50:6
> > preempt_count: 1, expected: 0
> > 6 locks held by kworker/u50:6/170:
> > #0: ffff000800206d48 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
> > process_one_work (kernel/workqueue.c:3232)
> > #1: ffff8000824f3d90 (deferred_probe_work){+.+.}-{0:0}, at:
> > process_one_work (kernel/workqueue.c:3233)
> > #2: ffff0008059920e8 (&dev->mutex){....}-{4:4}, at: __device_attach
> > (drivers/base/dd.c:1007)
> > #3: ffff0008196a3ee8 (&gdev->srcu){.+.+}-{0:0}, at:
> > gpiod_direction_output_raw_commit (drivers/gpio/gpiolib.c:2927)
> > #4: ffff0008197434b8 (&shared_desc->spinlock){....}-{3:3}, at:
> > gpio_shared_proxy_direction_output (drivers/gpio/gpiolib-shared.h:52
> > (discriminator 7) drivers/gpio/gpio-shared-proxy.c:181 (discriminator
> > 7)) gpio_shared_proxy
> > #5: ffff000813758ee8 (&gdev->srcu){.+.+}-{0:0}, at:
> > gpiod_direction_output_raw_commit (drivers/gpio/gpiolib.c:2927)
> > irq event stamp: 117306
> > hardirqs last enabled at (117305): _raw_spin_unlock_irqrestore
> > (./arch/arm64/include/asm/alternative-macros.h:254
> > ./arch/arm64/include/asm/cpufeature.h:809
> > ./arch/arm64/include/asm/irqflags.h:192
> > ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)
> > hardirqs last disabled at (117306): _raw_spin_lock_irqsave
> > (./include/linux/spinlock_api_smp.h:108 (discriminator 7)
> > kernel/locking/spinlock.c:162 (discriminator 7))
> > softirqs last enabled at (117044): handle_softirqs
> > (./arch/arm64/include/asm/current.h:19
> > ./arch/arm64/include/asm/preempt.h:12 kernel/softirq.c:469
> > kernel/softirq.c:650)
> > softirqs last disabled at (117033): __do_softirq (kernel/softirq.c:657)
> > CPU: 5 UID: 0 PID: 170 Comm: kworker/u50:6 Tainted: G  E 6.19.0-rc2 #4
> > PREEMPTLAZY
> > Tainted: [E]=UNSIGNED_MODULE
> > Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN60WW 09/11/2025
> > Workqueue: events_unbound deferred_probe_work_func
> > Call trace:
> > show_stack (arch/arm64/kernel/stacktrace.c:501) (C)
> > dump_stack_lvl (lib/dump_stack.c:122)
> > dump_stack (lib/dump_stack.c:130)
> > __might_resched (kernel/sched/core.c:8828)
> > __might_sleep (kernel/sched/core.c:8757)
> > __mutex_lock (kernel/locking/mutex.c:593 kernel/locking/mutex.c:776)
> > mutex_lock_nested (kernel/locking/mutex.c:829)
> >  lpi_config_set (drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:296) pinctrl_lpass_lpi
> >  lpi_gpio_direction_output
>
> Hi! The fix for that has been on the list for a while and I see Linus
> just picked it up. Please see if this fixes the issue for you:
>
> https://lore.kernel.org/all/20251126122219.25729-1-brgl@bgdev.pl/

Good catch; I find this addresses the lockdep warning and should be
introduced into 6.19-rc.

Tested-by: Daniel J Blueman <daniel@...ra.org>
-- 
Daniel J Blueman