public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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