All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Prakhya, Sai Praneeth" <sai.praneeth.prakhya@intel.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>
Subject: RE: [PATCH] iommu: Remove functions that support private domain
Date: Thu, 28 May 2020 19:31:40 +0000	[thread overview]
Message-ID: <FFF73D592F13FD46B8700F0A279B802F573BC50C@ORSMSX114.amr.corp.intel.com> (raw)
In-Reply-To: <20200525135644.GC5221@8bytes.org>

Hi Joerg,

> -----Original Message-----
> From: Joerg Roedel <joro@8bytes.org>
> Sent: Monday, May 25, 2020 6:57 AM
> To: Prakhya, Sai Praneeth <sai.praneeth.prakhya@intel.com>
> Cc: Lu Baolu <baolu.lu@linux.intel.com>; iommu@lists.linux-foundation.org
> Subject: Re: [PATCH] iommu: Remove functions that support private domain
> 
> On Sun, May 17, 2020 at 08:29:17AM +0000, Prakhya, Sai Praneeth wrote:
> > iommu_bus_notifier()
> > -> iommu_release_device()
> >  -> ops->release_device() (Eg: intel_iommu_release_device())
> >   -> iommu_group_remove_device()
> >    -> mutex_lock()
> >
> > But, I added print statements to iommu_bus_notifier() and
> > iommu_group_remove_device() and noticed that
> > iommu_group_remove_device() wasn't being called upon modprobe -r
> > <driver_name> and iommu_probe_device() isn't called upon modprobe
> > <driver_name> because
> 
> Calling modprobe is the device driver binding path, the release_device event is
> called when a device is going away, e.g. on hotunplug or when a VF of a PCI
> device is released.
> 
> This could also happen at runtime, and the code needs to protect against that.
> My suggestion is still to limit runtime-changing of default domains to groups
> with only one device. The flow would be as follows:

Thanks for explaining how lock release path could be called at run time. It makes sense to me now.

> 
> 	1. device_lock(dev);
> 	   // Device can't be bound to a driver or hot-removed from now
> 	   // on.
> 
> 	2. if (device_is_bound_to_some_driver(dev))
> 	           goto 6;
> 
> 	3. mutex_lock(&group->mutex);
> 	   // group of dev
> 
> 	4. Change the default domain
> 
> 	5. mutex_unlock(&group->mutex);
> 
> 	6. device_unlock(dev);
> 
> This avoids lock inversion and should be safe with regard to hotplug and device
> driver probing.

Thanks for the steps. I have implemented "changing default domain" following the steps you gave above. Could you please review the patch set when you have some time and let me know your comments?

Regards,
Sai
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-05-28 19:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 22:47 [PATCH] iommu: Remove functions that support private domain Sai Praneeth Prakhya
2020-05-14 13:13 ` Joerg Roedel
2020-05-14 17:51   ` Prakhya, Sai Praneeth
2020-05-14 18:32     ` Joerg Roedel
2020-05-14 18:44       ` Prakhya, Sai Praneeth
2020-05-14 19:56         ` Joerg Roedel
2020-05-14 23:12           ` Prakhya, Sai Praneeth
2020-05-15  9:59             ` Joerg Roedel
2020-05-15 12:55               ` Lu Baolu
2020-05-15 15:46                 ` Joerg Roedel
2020-05-17  8:29                   ` Prakhya, Sai Praneeth
2020-05-25 13:56                     ` Joerg Roedel
2020-05-28 19:31                       ` Prakhya, Sai Praneeth [this message]
2020-05-15 18:35               ` Prakhya, Sai Praneeth
2020-05-15 10:01 ` Joerg Roedel

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=FFF73D592F13FD46B8700F0A279B802F573BC50C@ORSMSX114.amr.corp.intel.com \
    --to=sai.praneeth.prakhya@intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    /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.