From: Greg KH <gregkh@linuxfoundation.org>
To: Danilo Krummrich <dakr@kernel.org>
Cc: Wang Jiayue <akaieurus@gmail.com>,
hanguidong02@gmail.com, rafael@kernel.org, Aishwarya.TCV@arm.com,
broonie@kernel.org, chenqiuji666@gmail.com,
linux-kernel@vger.kernel.org, m.szyprowski@samsung.com,
robin.clark@oss.qualcomm.com, will@kernel.org,
robin.murphy@arm.com, joro@8bytes.org, iommu@lists.linux.dev
Subject: Re: [PATCH v5] driver core: enforce device_lock for driver_match_device()
Date: Wed, 21 Jan 2026 12:19:10 +0100 [thread overview]
Message-ID: <2026012126-coke-lash-dd99@gregkh> (raw)
In-Reply-To: <DFU7SVI5SYE5.3MJP2ECGGZK5P@kernel.org>
On Wed, Jan 21, 2026 at 12:02:15PM +0100, Danilo Krummrich wrote:
> On Wed Jan 21, 2026 at 11:40 AM CET, Danilo Krummrich wrote:
> > So, the problem is that in the callstack of the arm-smmu driver's (a platform
> > driver) probe() function, the QCOM specific code (through arm_smmu_impl_init())
> > registers another platform driver. Since we are still in probe() of arm-smmu the
> > call to platform_driver_register() happens with the device lock of the arm-smmu
> > platform device held.
> >
> > platform_driver_register() eventually results in driver_attach() which iterates
> > over all the devices of a bus. Since the device we are probing and the driver we
> > are registering are for the same bus (i.e. the platform bus) it can now happen
> > that by chance that we also match the exact same device that is currently probed
> > again. And since we take the device lock for matching now, we actually take the
> > same lock twice.
> >
> > Now, we could avoid this by not matching bound devices, but we check this
> > through dev->driver while holding the device lock, so that doesn't help.
> >
> > But on the other hand, I don't see any reason why a driver would call
> > platform_driver_register() from probe() in the first place. I think drivers
> > should not do that and instead just register the driver through a normal
> > initcall.
> >
> > (If, however, it turns out that registering drivers from probe() is something we
> > really need for some reason, it is probably best to drop the patch and don't
> > make any guarantees about whether match() is called with the device lock held or
> > not.
> >
> > Consequently, driver_override must be protected with a separate lock (which
> > would be the cleaner solution in any case).)
>
> I assume that this should resolve the problem (unless there are more drivers
> that register drivers in probe()):
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index 573085349df3..9bb793efc35f 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -774,10 +774,6 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
> {
> const struct device_node *np = smmu->dev->of_node;
> const struct of_device_id *match;
> - static u8 tbu_registered;
> -
> - if (!tbu_registered++)
> - platform_driver_register(&qcom_smmu_tbu_driver);
Ick, yeah, that should not be happening. We should deadlock on that no
matter what.
>
> #ifdef CONFIG_ACPI
> if (np == NULL) {
> @@ -802,3 +798,5 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
>
> return smmu;
> }
> +
> +builtin_platform_driver(qcom_smmu_tbu_driver);
change makes sense to me.
thanks,
greg k-h
next prev parent reply other threads:[~2026-01-21 11:19 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 16:28 [PATCH v5] driver core: enforce device_lock for driver_match_device() Gui-Dong Han
2026-01-13 16:35 ` Rafael J. Wysocki
2026-01-13 19:23 ` Danilo Krummrich
2026-01-16 7:34 ` Gui-Dong Han
2026-01-16 11:19 ` Greg KH
2026-01-16 11:38 ` Gui-Dong Han
2026-01-16 11:54 ` Danilo Krummrich
2026-01-20 13:22 ` Mark Brown
2026-01-20 13:30 ` Gui-Dong Han
2026-01-20 13:48 ` Mark Brown
2026-01-20 14:05 ` Gui-Dong Han
2026-01-21 8:55 ` Wang Jiayue
2026-01-21 8:57 ` Gui-Dong Han
2026-01-21 10:40 ` Danilo Krummrich
2026-01-21 11:02 ` Danilo Krummrich
2026-01-21 11:19 ` Greg KH [this message]
2026-01-21 12:49 ` Mark Brown
2026-01-21 12:50 ` Danilo Krummrich
2026-01-21 13:02 ` Will Deacon
2026-01-21 14:07 ` Danilo Krummrich
2026-01-21 13:03 ` Robin Murphy
2026-01-21 14:13 ` Danilo Krummrich
2026-01-21 13:22 ` Jiayue Wang
2026-01-20 15:03 ` Danilo Krummrich
2026-01-20 15:35 ` Mark Brown
2026-01-20 17:38 ` Mark Brown
2026-01-20 18:36 ` Danilo Krummrich
2026-01-20 20:05 ` Mark Brown
2026-01-20 21:18 ` Danilo Krummrich
2026-01-21 1:11 ` Danilo Krummrich
2026-01-21 7:18 ` Gui-Dong Han
2026-01-21 7:41 ` Gui-Dong Han
2026-01-21 7:56 ` Greg KH
2026-01-21 8:12 ` Greg KH
2026-01-21 9:54 ` Danilo Krummrich
2026-01-21 10:30 ` Greg KH
2026-01-20 15:23 ` Marek Szyprowski
2026-01-20 15:27 ` Mark Brown
2026-01-21 20:00 ` Jon Hunter
2026-01-21 21:42 ` Danilo Krummrich
2026-01-22 17:28 ` Jon Hunter
2026-01-22 17:55 ` Gui-Dong Han
2026-01-22 18:12 ` Danilo Krummrich
2026-01-22 18:58 ` Jon Hunter
2026-01-22 19:35 ` Danilo Krummrich
2026-01-23 13:57 ` Jon Hunter
2026-01-23 14:09 ` Danilo Krummrich
2026-01-23 14:29 ` Jon Hunter
2026-01-23 16:54 ` Danilo Krummrich
2026-01-23 18:53 ` Gui-Dong Han
2026-01-23 19:07 ` Danilo Krummrich
2026-01-27 14:58 ` Jon Hunter
2026-01-27 15:18 ` Danilo Krummrich
2026-01-27 14:53 ` Jon Hunter
2026-01-27 15:05 ` Gui-Dong Han
2026-01-21 7:40 ` David Heidelberg
2026-02-11 10:42 ` Alexander Stein
2026-02-11 13:56 ` Danilo Krummrich
2026-02-25 20:19 ` Cristian Marussi
2026-02-25 20:38 ` Danilo Krummrich
2026-02-26 8:54 ` Gatien CHEVALLIER
2026-02-26 11:15 ` Danilo Krummrich
2026-02-26 12:21 ` Cristian Marussi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026012126-coke-lash-dd99@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Aishwarya.TCV@arm.com \
--cc=akaieurus@gmail.com \
--cc=broonie@kernel.org \
--cc=chenqiuji666@gmail.com \
--cc=dakr@kernel.org \
--cc=hanguidong02@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=rafael@kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox