From: Greg KH <gregkh@linuxfoundation.org>
To: Hannes Reinecke <hare@suse.com>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] (PCI) driver rebinding
Date: Mon, 26 Jun 2017 08:57:24 +0200 [thread overview]
Message-ID: <20170626065724.GA31701@kroah.com> (raw)
In-Reply-To: <98ef581a-1618-623f-d52c-77fec798fb52@suse.com>
On Mon, Jun 26, 2017 at 08:05:53AM +0200, Hannes Reinecke wrote:
> On 06/26/2017 06:59 AM, Greg KH wrote:
> > How will udev and systemd have "races"? We do this today all the time
> > in USB with the usb-modeswitch userspace code, as you point out.
> >
> The problem here is that we will be generating lots of invalid devices
> (ie devices which are only present in one mode, but not the other).
> So if we start off with a default mode the driver might be creating lots
> of devices, which will be torn down once the device is switched to the
> configured mode.
> _If_ for some reason one of these invalid devices has the same
> identifier as one of the 'real' devices (think of eg multipathing),
> udev/systemd will start processing this device.
> But then we're killing that device shortly afterwards, making systemd
> very unhappy and the user left with a stalled system.
If you have someone adding/removing a device on a pcie link (or
thunderbolt) really quickly, you are going to have this same "issue", so
it's something you are going to have to handle anyway. Odds are it's
not going to be all that complex, userspace, if it is sane, should be
fine.
But you are talking "multipath", which is not sane, good luck! :)
> So I'd rather not go down that way; ideally I would have the driver
> start off in the 'correct' mode so that the above issue doesn't occur.
I agree.
> >> - Inhibit default binding, and load the correct drivers after the
> >> configuration has been read.
> >
> > You can do that too vfio does it from what I recall. It's easy in that
> > you can just not do a MODULE_DEVICE_TABLE() export and no driver will
> > automatically be loaded and userspace is required to load what it wants.
> >
> Yeah; however, if we do this, we either have to kill the module device
> table from the driver (but how would the driver then know which device
> to bind to?) or we have to kill the autoloading from the bus (but then
> _none_ of the drivers will load, impacting the entire system).
No, MODULE_DEVICE_TABLE is only needed for auto-loading of modules, it
does not affect what drivers bind to what devices at all. Once the
module is loaded, all should "just work", unless you have multiple
drivers that say they bind to the same devices, then you have the same
issue as before.
> While I would prefer this option I'm not sure how we can achieve this
> sanely.
> vfio doesn't really count here, as this is a generic PCI driver which
> would work with any PCI device (at least in theory).
That sounds exactly what vfio does, they handle this all in userspace,
and do crazy stuff with the bind/unbind sysfs attributes. That might
work here too if you have to do it in the end.
thanks,
greg k-h
next prev parent reply other threads:[~2017-06-26 6:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-25 15:39 Hannes Reinecke
2017-06-25 21:38 ` Matthew Wilcox
2017-06-26 5:54 ` Hannes Reinecke
2017-06-26 4:59 ` Greg KH
2017-06-26 6:05 ` Hannes Reinecke
2017-06-26 6:57 ` Greg KH [this message]
2017-06-26 5:37 ` Leon Romanovsky
2017-06-26 5:44 ` Bart Van Assche
2017-06-26 17:40 ` Lee Duncan
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=20170626065724.GA31701@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=hare@suse.com \
--cc=ksummit-discuss@lists.linuxfoundation.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