From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C1E644CAF8 for ; Tue, 20 Jan 2026 15:03:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768921387; cv=none; b=BrrbbeDT9Rwq1gSTLr14SO8fX1+KrpiPq0Fv7AKxEZC5F9HH/EKiQBjsOqZnLqhe2CLeXhIs6hexaMnz794fJVxhmwwAQ0L0CY3FRdWyVYTOVInjZOqSGCC5jwIA2+SBDumI8UrNjEtcOpbRZeDQV+HhX5H0zlT4abQaDKIFxZE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768921387; c=relaxed/simple; bh=MELPUE+fDtFCDWYlAg/+wK87e6anoQm7ySpRhZwtckk=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=ZblPhsO5ZMrJbisfZs5cFhxKt0JnW/k5z60Kg+EQR9uLdXtMsgerGxACuCzpLW2NJ0lyZv1+GNV4DjyWUQbHJLIwAOlK6Z3yyJggKSCSSsbBR9xGFPgDkvrdCIA6Wu+bWprJw5Blx451JImLHkH1T6ImVgwN/+303hp7vxz7wo0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rvZ6t4FJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rvZ6t4FJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2572C19422; Tue, 20 Jan 2026 15:03:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768921387; bh=MELPUE+fDtFCDWYlAg/+wK87e6anoQm7ySpRhZwtckk=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=rvZ6t4FJi1M2YNz4ktRMR+cwOigng9tPm3yISEUESEAMmY8eKvA9d/p51yvssIsBB FEWkKfB1lUIHnSnT26QfPf5saGIYtbLi6WVvubtAENdoaLNMY6+Uh36C+KhA2UnfdO hExMo1VmmctGDzA+Y0A5RiHXdvtegJNWqJmji/ceduQkSNlCmzVkPOu/EhHwYRTPyX 57plWU1BBJ34/Vz8yrf3/8LA5YlVTUQ4EySYK0554WbOZIW8W2URsvI0coIrSvlv4e o4NLjzJOBtAlXr3rrx9csQwi34Teu2ryidaClVBymjmHmkknVmArfDOaDcup/YtndF TYXi1h7IAzpcQ== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 20 Jan 2026 16:03:03 +0100 Message-Id: Subject: Re: [PATCH v5] driver core: enforce device_lock for driver_match_device() Cc: "Gui-Dong Han" , , , , , "Qiu-ji Chen" , To: "Mark Brown" From: "Danilo Krummrich" References: <20260113162843.12712-1-hanguidong02@gmail.com> <7ae38e31-ef31-43ad-9106-7c76ea0e8596@sirena.org.uk> In-Reply-To: <7ae38e31-ef31-43ad-9106-7c76ea0e8596@sirena.org.uk> On Tue Jan 20, 2026 at 2:22 PM CET, Mark Brown wrote: > On Wed, Jan 14, 2026 at 12:28:43AM +0800, Gui-Dong Han wrote: >> Currently, driver_match_device() is called from three sites. One site >> (__device_attach_driver) holds device_lock(dev), but the other two >> (bind_store and __driver_attach) do not. This inconsistency means that >> bus match() callbacks are not guaranteed to be called with the lock >> held. > > 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 Hm..sounds a bit like some match() callback manually takes the device_lock(= ) and the reason we're not seeing anything from lockdep is because it happens wit= h the serial driver. I don't have a machine to reproduce it, but for debugging it would probably= help to not actually take the lock in __driver_attach(), but only acquire / rele= ase the corresponding lockdep map. If my suspicion is correct, we should see a lockdep splat pointing out the issue.