linux-kernel - Re: [RFD] Functional dependencies between devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2017403.WqCaz90jK6@vostro.rjw.lan>
Date:	Mon, 09 Nov 2015 22:42:04 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Thierry Reding <treding@...dia.com>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Brown <broonie@...nel.og>, Rob Herring <robh@...nel.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Dmitry Torokhov <dtor@...gle.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Michael Turquette <mturquette@...libre.com>
Subject: Re: [RFD] Functional dependencies between devices

On Monday, November 09, 2015 01:32:04 PM Thierry Reding wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> [...]
> > There's a question about what if the supplier device is being unbound before
> > the consumer one (for example, as a result of a hotplug event).  My current
> > view on that is that the consumer needs to be force-unbound in that case too,
> > but I guess I may be persuaded otherwise given sufficiently convincing
> > arguments.
> 
> I think this would be a huge step towards making the kernel more robust
> with little driver or subsystem code having to be duplicated. Currently
> most provider/consumer subsystems are fragile in that there isn't proper
> reference counting. Many subsystems will happily allow you to remove any
> of the provider, regardless of whether or not it has consumers. Most of
> the subsystems will make sure that modules can't be unloaded, but beyond
> that won't be able to prevent drivers from being unbound (either when a
> device is unplugged or unbound via sysfs). Even with proper reference
> counting there is no easy way to deal with devices going away (you'd
> need some sort of revoke semantics implemented for all providers, and
> consumers must be able to handle that situation gracefully).
> 
> Implementing a force-unbind policy would make this a whole lot easier.
> Dangling resources will automatically become a thing of the past. The
> downside of course is that force-unbinding consumers may not always be
> the most user-friendly course of action. Consider an SD/MMC slot that
> uses a GPIO as card-detect pin. Unbinding the provider of the GPIO
> would cause the SD/ MMC controller to be unbound, hence unmounting the
> filesystem that it provided. That filesystem might have been the root
> filesystem.

Well, the problem is that device_release_driver() cannot fail, so it
pretty much has to unbind everything that is not going to work after the
driver is unbound from the device.

> We discussed similar use-cases a while back and you proposed making the
> force-unbind policy be two-staged: reject unbind (-EBUSY) if there are
> any consumers, and force-unbind consumers if the provider was forcibly
> unbound (or caused by hot-unplug of the backing device). That sounds
> like a good compromise to me.

That can be done for bus types having device_offline/online() support,
but the number of these is quite limited at this point.

The "offline" operation, as opposed to device_release_driver(), can return
an error code to indicate that the device cannot be taken offline at this
time.  So, if offlining a supplier would require offlining all consumers
of it, that may be made fail in certain situation.  However, that would
require quite a bit of additional structure (and complexity) in pretty
much all bus types, so I wouldn't start with it at least. 

> That said I can also imagine subsystems where a reliable mechanism is in
> place to properly hotplug and -unplug providers. The good thing about
> the functional dependencies mechanism you propose here is that it's an
> optional mechanism that drivers use from ->probe(). Subsystems where a
> better mechanism exists can simply choose to do without functional
> dependencies.

I actually think that those things are at least partly orthogonal.

Thanks,
Rafael

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)