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: <20151109123202.GC23941@ulmo.nvidia.com>
Date:	Mon, 9 Nov 2015 13:32:04 +0100
From:	Thierry Reding <treding@...dia.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
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 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.

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 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.

Thierry

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