mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org
Cc: linux@armlinux.org.uk, kvm@vger.kernel.org
Subject: [RFC PATCH] driver core: Stop driver bind on NOTIFY_BAD
Date: Mon, 26 Jun 2017 13:35:50 -0600	[thread overview]
Message-ID: <20170626192117.1412.50230.stgit@gimli.home> (raw)

Allow participants in the BUS_NOTIFY_BIND_DRIVER to prevent driver
binding with a NOTIFY_BAD.  An example case where this might be useful
is when we're dealing with IOMMU groups and userspace drivers.  We've
defined that devices within the same IOMMU group are not necessarily
DMA isolated from one another and therefore allowing those devices to
be split between host and user drivers may compromise the kernel.  The
vfio driver currently handles this with a BUG_ON when such a condition
occurs.  A better solution is to prevent the case from occurring,
which this change enables.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Suggested-by: Russell King <linux@armlinux.org.uk>
---
 drivers/base/dd.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

For due diligence, none of the current notifier blocks registered with
bus_register_notifier() return anything other than { 0, NOTIFY_OK,
NOTIFY_DONE } except for the case of BUS_NOTIFY_ADD_DEVICE, where
NOTIFY_BAD is possible for NULL data in keystone_platform_notifier()
and an errno return is possible from tce_iommu_bus_notifier() and
i2cdev_notifier_call().  device_add() also ignores the call chain
return value, so these three cases are all ineffective at preventing
anything.

If this is acceptable, I'll re-spin https://lkml.org/lkml/2017/6/20/681
dropping the last 3 patches, instead using the patch below, plumbing
the IOMMU group notifier to percolate notifier block returns, and
simply return NOTIFY_BAD from vfio rather than mucking with
driver_override.  Thanks

Alex 

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4882f06d12df..32c1d841e8d9 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -265,9 +265,11 @@ static int driver_sysfs_add(struct device *dev)
 {
 	int ret;
 
-	if (dev->bus)
-		blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
-					     BUS_NOTIFY_BIND_DRIVER, dev);
+	if (dev->bus) {
+		if (blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
+				BUS_NOTIFY_BIND_DRIVER, dev) == NOTIFY_BAD)
+			return -EINVAL;
+	}
 
 	ret = sysfs_create_link(&dev->driver->p->kobj, &dev->kobj,
 			  kobject_name(&dev->kobj));

             reply	other threads:[~2017-06-26 19:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 19:35 Alex Williamson [this message]
2017-06-27  7:00 ` Greg KH
2017-06-27 20:18   ` Alex Williamson

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=20170626192117.1412.50230.stgit@gimli.home \
    --to=alex.williamson@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®