[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250221164854.GO50639@nvidia.com>
Date: Fri, 21 Feb 2025 12:48:54 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Robin Murphy <robin.murphy@....com>
Cc: Nicolin Chen <nicolinc@...dia.com>, kevin.tian@...el.com,
tglx@...utronix.de, maz@...nel.org, joro@...tes.org,
will@...nel.org, shuah@...nel.org, iommu@...ts.linux.dev,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kselftest@...r.kernel.org, eric.auger@...hat.com,
baolu.lu@...ux.intel.com, yi.l.liu@...el.com, yury.norov@...il.com,
jacob.pan@...ux.microsoft.com, patches@...ts.linux.dev
Subject: Re: [PATCH v2 7/7] iommu: Turn iova_cookie to dma-iommu private
pointer
On Fri, Feb 21, 2025 at 03:23:22PM +0000, Robin Murphy wrote:
> Eww... What's the issue with just checking the domain type in
> iommu_put_dma_cookie()? Is is that IOMMUFD and VFIO type 1 are both doing
> their own different thing with IOMMU_DOMAIN_UNMANAGED?
Yes
> In general it seems like a bad smell to have a union in a structure with not
> enough information within that structire itself to know which union member
> is valid... :/
The concept is the opaque pointer belongs only to the caller that
allocated and owns the domain. The core iommu code should never look
at it or touch it.
The problem is with the mandatory call to dma-iommu in the free path -
dma-iommu code should never be invoked outside of VFIO and the default
domain cases.
So the little rework I sketched makes it into the caller knowing if
dma-iommu is operating that domain and then only does it call the
dma-iommu related functions, and the core code never touches the union
content.
Jason
Powered by blists - more mailing lists