linux-kernel - Re: [PATCH v5] driver core: enforce device_lock for driver_match

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CALbr=La6j6uCsPoT1=0PO-Pg1cRxKE+98EP6+W06Jp71KK+-3A@mail.gmail.com>
Date: Wed, 21 Jan 2026 16:57:46 +0800
From: Gui-Dong Han <hanguidong02@...il.com>
To: Wang Jiayue <akaieurus@...il.com>
Cc: Aishwarya.TCV@....com, broonie@...nel.org, chenqiuji666@...il.com, 
	dakr@...nel.org, gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org, 
	rafael@...nel.org
Subject: Re: [PATCH v5] driver core: enforce device_lock for driver_match_device()

On Wed, Jan 21, 2026 at 4:56 PM Wang Jiayue <akaieurus@...il.com> wrote:
>
> > I'm seeing boot hangs on Arm Juno in next/pending-fixes which bisect to
> > this commit.  The boot grinds to a halt near the end of boot:
> >
> > [    2.570549] ledtrig-cpu: registered to indicate activity on CPUs
> > [    2.618301] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> > [    2.623547] msm_serial: driver initialized
> > [    2.624058] SuperH (H)SCI(F) driver initialized
> > [    2.624312] STM32 USART driver initialized
>
> After partially modifying juno.dts, I managed to roughly emulate kernel
> boot on juno board with qemu and successfully reproduced the boot hang.
> Below is the gdb backtrace:

Great work, thank you very much!

This is a bit puzzling to me. Since __device_driver_lock(dev,
dev->parent) is called a few lines later in __driver_attach(), I
wonder if the original kernel would also deadlock if match() returns
true in such a nested scenario?

Thanks.