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: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CALbr=LYt-MqGM0ua78Rt7M679WR9hNnk0Or-WrB2myZ=KhaN0w@mail.gmail.com>
[not found] ` <20260121085549.165428-1-akaieurus@gmail.com>
2026-01-21 10:40 ` [PATCH v5] driver core: enforce device_lock for driver_match_device() 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
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