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));
next 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®