linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiang Liu <liuj97@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Yinghai Lu <yinghai@kernel.org>, Jiang Liu <jiang.liu@huawei.com>,
	Joerg Roedel <joerg.roedel@amd.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Hanjun Guo <guohanjun@huawei.com>
Subject: Re: [RFC PATCH 1/6] driver core: add a bus notification to temporarily reject driver binding
Date: Wed, 14 Nov 2012 00:02:47 +0800	[thread overview]
Message-ID: <50A26F27.3070806@gmail.com> (raw)
In-Reply-To: <20121111052152.GA5795@kroah.com>

On 11/11/2012 01:21 PM, Greg Kroah-Hartman wrote:
> On Sat, Nov 10, 2012 at 09:57:14PM +0800, Jiang Liu wrote:
>>  From: Jiang Liu <jiang.liu@huawei.com>
>>
>> There are several requirements to temporarily reject device driver
>> binding. Possible usage cases as below:
>> 1) We should avoid binding an unsafe driver to a device belonging to
>>    an active VFIO group, otherwise it will break the DMA isolation
>>    property of VFIO.
>> 2) When hot-removing a PCI hierachy, we should avoid binding device
>>    drivers to PCI devices going to be removed during the window
>>    between unbinding of device driver and destroying of device nodes.
>> 3) When hot-adding a PCI host bridge, we should temporarily disable
>>    driver binding before setting up corresponding IOMMU and IOAPIC.
>>
>> We may add a flag into struct device to temporarily disable driver
>> binding as in this thread https://patchwork.kernel.org/patch/1535721/.
> 
> I totally do not understand.  The bus controls this, if it does not want
> to bind a device to a driver, then don't do it.  It's really quite
> simple to just block the probe callback the bus gets, right?  Why create
> all of this extra, and confusing, interface instead?
Hi Greg,
	Thanks for your comments. 
	As you know, we already have an "drivers_autoprobe" flag for drivers,
we are trying to provide a similar mechanism for devices.
	But I'm not sure whether we could block the probe callback. For PCI
host bridge hotplug, that will effectively block the PCI host bridge hotplug
thread. For VFIO case, its goal is to reject binding unsafe drivers to PCI
devices belonging to active VFIO group, so it doesn't make sense to block
the driver probing thread too. So we are trying to return error code instead
of blocking in really_probe().
	Thanks!
	Gerry

> 
>> This patch proposes another solution to temporarily disable driver
>> binding by using bus notification mechanisms. It adds an notification
>> event to solicit if anybody has objections when binding a driver to a
>> device.
> 
> Sorry, but no, don't do this, it's way more confusing.
> 
> greg k-h
> 


      reply	other threads:[~2012-11-13 16:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-10 13:57 [RFC PATCH 1/6] driver core: add a bus notification to temporarily reject driver binding Jiang Liu
2012-11-10 13:57 ` [RFC PATCH 2/6] iommu: pass on BUS_NOTIFY_QUERY_BINDING to iommu group notifier clients Jiang Liu
2012-11-10 13:57 ` [RFC PATCH 3/6] VFIO: unregister IOMMU notifier on error recovery path Jiang Liu
2012-11-13 18:15   ` Alex Williamson
2012-11-10 13:57 ` [RFC PATCH 4/6] VFIO: reject binding driver to devices belonging to active VFIO groups Jiang Liu
2012-11-10 13:57 ` [RFC PATCH 5/6] VFIO: simplify IOMMU group notification handler Jiang Liu
2012-11-10 13:57 ` [RFC PATCH 6/6] VFIO: use ACCESS_ONCE() to guard access to dev->driver Jiang Liu
2012-11-11  5:21 ` [RFC PATCH 1/6] driver core: add a bus notification to temporarily reject driver binding Greg Kroah-Hartman
2012-11-13 16:02   ` Jiang Liu [this message]

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=50A26F27.3070806@gmail.com \
    --to=liuj97@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=jiang.liu@huawei.com \
    --cc=joerg.roedel@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yinghai@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).