All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Will McVicker <willmcvicker@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	"Rob Herring (Arm)" <robh@kernel.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <jroedel@suse.de>,
	Bjorn Helgaas <bhelgaas@google.com>,
	iommu@lists.linux.dev, Saravana Kannan <saravanak@google.com>,
	kernel-team@android.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] platform: Fix race condition during DMA configure at IOMMU probe time
Date: Wed, 23 Apr 2025 10:08:23 -0500	[thread overview]
Message-ID: <20250423150823.GA422889@bhelgaas> (raw)
In-Reply-To: <20250422232650.2737369-1-willmcvicker@google.com>

On Tue, Apr 22, 2025 at 04:26:49PM -0700, Will McVicker wrote:
> If devices are probed asynchronously, then there is a chance that during
> the IOMMU probe the driver is bound to the device in parallel. If this
> happens after getting the platform_driver pointer while in the function
> `platform_dma_configure()`, then the invalid `drv` pointer
> (drv==0xf...ffd8) will be de-referenced since `dev->driver != NULL`.

I need a little more hand-holding to make sense out of this.

After digging out
https://lore.kernel.org/all/aAa2Zx86yUfayPSG@google.com/, I see that
drv==0xf...ffd8 must be a result of applying to_platform_driver() to a
NULL pointer.  This patch still applies to_platform_driver(NULL), but
avoids using the result by testing drv for NULL later, which seems
prone to error.

I think this would all be clearer if we tested for the NULL pointer
explicitly before applying to_platform_driver().  I don't like setting
a pointer to an invalid value.  I think it's better if the pointer is
either valid or uninitialized because the compiler can help find uses
of uninitialized pointers.

> To avoid a kernel panic and eliminate the race condition, we should
> guard the usage of `dev->driver` by only reading it once at the
> beginning of the function.
> 
> Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")
> Signed-off-by: Will McVicker <willmcvicker@google.com>
> ---
>  drivers/base/platform.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 1813cfd0c4bd..b948c6e8e939 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1440,7 +1440,8 @@ static void platform_shutdown(struct device *_dev)
>  
>  static int platform_dma_configure(struct device *dev)
>  {
> -	struct platform_driver *drv = to_platform_driver(dev->driver);
> +	struct device_driver *drv = READ_ONCE(dev->driver);
> +	struct platform_driver *pdrv = to_platform_driver(drv);
>  	struct fwnode_handle *fwnode = dev_fwnode(dev);
>  	enum dev_dma_attr attr;
>  	int ret = 0;
> @@ -1451,8 +1452,8 @@ static int platform_dma_configure(struct device *dev)
>  		attr = acpi_get_dma_attr(to_acpi_device_node(fwnode));
>  		ret = acpi_dma_configure(dev, attr);
>  	}
> -	/* @drv may not be valid when we're called from the IOMMU layer */
> -	if (ret || !dev->driver || drv->driver_managed_dma)
> +	/* @dev->driver may not be valid when we're called from the IOMMU layer */
> +	if (ret || !drv || pdrv->driver_managed_dma)
>  		return ret;
>  
>  	ret = iommu_device_use_default_domain(dev);
> -- 
> 2.49.0.805.g082f7c87e0-goog
> 

  reply	other threads:[~2025-04-23 15:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-22 23:26 [PATCH v1] platform: Fix race condition during DMA configure at IOMMU probe time Will McVicker
2025-04-23 15:08 ` Bjorn Helgaas [this message]
2025-04-23 15:50   ` Robin Murphy
2025-04-23 16:57     ` Jason Gunthorpe
2025-04-23 17:27     ` William McVicker
2025-04-23 16:58   ` Jason Gunthorpe

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=20250423150823.GA422889@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dakr@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jroedel@suse.de \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=saravanak@google.com \
    --cc=willmcvicker@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.