lkml.org 
[lkml]   [2024]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v4 2/9] iommu: Replace sva_iommu with iommu_attach_handle
Date
> From: Baolu Lu <baolu.lu@linux.intel.com>
> Sent: Sunday, April 28, 2024 6:22 PM
>
> On 2024/4/10 7:48, Jason Gunthorpe wrote:
> > On Tue, Apr 09, 2024 at 10:11:28AM +0800, Baolu Lu wrote:
> >> On 4/8/24 10:19 PM, Jason Gunthorpe wrote:
> >>> On Sat, Apr 06, 2024 at 02:09:34PM +0800, Baolu Lu wrote:
> >>>> On 4/3/24 7:59 PM, Jason Gunthorpe wrote:
> >>>>> On Wed, Apr 03, 2024 at 09:15:12AM +0800, Lu Baolu wrote:
> >>>>>> + /* A bond already exists, just take a reference`. */
> >>>>>> + handle = iommu_attach_handle_get(group, iommu_mm-
> >pasid);
> >>>>>> + if (handle) {
> >>>>>> + mutex_unlock(&iommu_sva_lock);
> >>>>>> + return handle;
> >>>>>> }
> >>>>> At least in this context this is not enough we need to ensure that the
> >>>>> domain on the PASID is actually an SVA domain and it was installed by
> >>>>> this mechanism, not an iommufd domain for instance.
> >>>>>
> >>>>> ie you probably need a type field in the iommu_attach_handle to tell
> >>>>> what the priv is.
> >>>>>
> >>>>> Otherwise this seems like a great idea!
> >>>> Yes, you are right. For the SVA case, I will add the following changes.
> >>>> The IOMMUFD path will also need such enhancement. I will update it in
> >>>> the next version.
> >>> The only use for this is the PRI callbacks right? Maybe instead of
> >>> adding a handle type let's just check domain->iopf_handler ?
> >>>
> >>> Ie SVA will pass &ommu_sva_iopf_handler as its "type"
> >> Sorry that I don't fully understand the proposal here.
> > I was talking specifically about the type field you suggested adding
> > to the handle struct.
> >
> > Instead of adding a type field check the domain->iopf_handler to
> > determine the domain and thus handle type.
> >
> >> The problem is that the context code (SVA, IOMMUFD, etc.) needs to
> make
> >> sure that the attach handle is really what it has installed during
> >> domain attachment. The context code needs some mechanism to include
> some
> >> kind of "owner cookie" in the attach handle, so that it could check
> >> against it later for valid use.
> > Right, you have a derived struct for each user and you need a way to
> > check if casting from the general handle struct to the derived struct
> > is OK.
> >
> > I'm suggesting using domain->iopf_handle as the type key.
>
> After removing the refcount from the attach handle, I am trying to make
> the code look like this,
>
> /* A bond already exists, just take a reference`. */
> handle = iommu_attach_handle_get(group, iommu_mm->pasid);
> if (handle) {
> if (handle->domain->iopf_handler !=
> iommu_sva_iopf_handler) {
> ret = -EBUSY;
> goto out_unlock;
> }
>
> refcount_inc(&handle->users);
> mutex_unlock(&iommu_sva_lock);
> return handle;
> }
>
> But it appears that this code is not lock safe. If the domain on the
> PASID is not a SVA domain, the check of "handle->domain->iopf_handler !=
> iommu_sva_iopf_handler" could result in a use-after-free issue as the
> other thread might detach the domain in between the fetch and check
> lines.
>
> Probably we still need to keep the refcount in the attach handle?
>

What about Jason's another comment in his original replies?

"
Though I'm not convinced the refcount should be elevated into the core
structure. The prior patch I showed you where the caller can provide
the memory for the handle and we don't have a priv would make it easy
to put the refcount in a SVA dervied handle struct without more
allocation. Then we don't need this weirdness.
"

That sounds like we'll need a iommu_sva like structure to hold
its own refcnt. Then we don't need this type check and refcnt
in the core.
\
 
 \ /
  Last update: 2024-04-29 04:39    [W:0.113 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site