[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+zVRrt7mGkqtBBo@nvidia.com>
Date: Wed, 15 Feb 2023 08:51:18 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: "Tian, Kevin" <kevin.tian@...el.com>,
"joro@...tes.org" <joro@...tes.org>,
"will@...nel.org" <will@...nel.org>,
"robin.murphy@....com" <robin.murphy@....com>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"shuah@...nel.org" <shuah@...nel.org>,
"Liu, Yi L" <yi.l.liu@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>
Subject: Re: [PATCH v2 08/10] iommufd/device: Use iommu_group_replace_domain()
On Tue, Feb 14, 2023 at 11:15:09PM -0800, Nicolin Chen wrote:
> But things will be out of control, if user space continues mapping
> something onto domain1's iopt for idev2, even after it is attached
> covertly to domain2's iopt by the replace routine. I wonder how
> kernel should handle this and keep the consistency between IOMMUFD
> objects and iommu_group.
I've been looking at this, the reason the locking is such a PITA is
because we are still trying to use the device list short cut.
We need to have a iommu group object instead then everything will work
smoothly.
Jason
Powered by blists - more mailing lists