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

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:


	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.

Regards,

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

  reply	other threads:[~2020-05-25 13:56 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 [this message]
2020-05-28 19:31                       ` Prakhya, Sai Praneeth
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=20200525135644.GC5221@8bytes.org \
    --to=joro@8bytes.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=sai.praneeth.prakhya@intel.com \
    /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.