[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250704152258.GL1410929@nvidia.com>
Date: Fri, 4 Jul 2025 12:22:58 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: joro@...tes.org, will@...nel.org, robin.murphy@....com,
rafael@...nel.org, lenb@...nel.org, bhelgaas@...gle.com,
iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
patches@...ts.linux.dev, pjaroszynski@...dia.com, vsethi@...dia.com,
helgaas@...nel.org, baolu.lu@...ux.intel.com
Subject: Re: [PATCH RFC v2 1/4] iommu: Lock group->mutex in
iommu_deferred_attach
On Sat, Jun 28, 2025 at 12:42:39AM -0700, Nicolin Chen wrote:
> The iommu_deferred_attach() is a runtime asynchronous function called by
> iommu-dma function, which will race against other attach functions if it
> accesses something in the dev->iommu_group.
>
> Grab the lock to protect it like others who call __iommu_attach_device()
> as it will need to access dev->iommu_group.
>
> Signed-off-by: Nicolin Chen <nicolinc@...dia.com>
> ---
> drivers/iommu/iommu.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
I vaugely recall seeing something like this before.
IIRC it can't actually race but there is no harm in taking the lock so
lockdep works reliably. It isn't fast path.
Reviewed-by: Jason Gunthorpe <jgg@...dia.com>
Jason
Powered by blists - more mailing lists