linux-kernel - Re: [PATCH] driver core: Ensure proper suspend/resume ordering

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: <Pine.LNX.4.44L0.1509211031210.1713-100000@iolanthe.rowland.org>
Date:	Mon, 21 Sep 2015 10:34:54 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Thierry Reding <thierry.reding@...il.com>
cc:	"Rafael J. Wysocki" <rafael@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Grygorii Strashko <grygorii.strashko@...com>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH] driver core: Ensure proper suspend/resume ordering

On Mon, 21 Sep 2015, Thierry Reding wrote:

> > > Force-removing drivers that depend on a device that's being unbound
> > > would be a possibility to solve the problem where consumers depend on a
> > > device that could physically go away. It might also be the right thing
> > > to do in any case. Presumably somebody unloading a module want to do
> > > just that, and refusing to do so isn't playing very nice. Of course
> > > allowing random modules to be removed even if a lot of consumers might
> > > depend on it may not be friendly either. Consider if you unload a GPIO
> > > driver that provides a pin that's used to enable power to an eMMC that
> > > might have the root filesystem.
> > >
> > > Then again, if you unload a module you better know what you're doing
> > > anyway, so maybe that's not something we need to be concerned about.
> > 
> > I think that it's better to fail module unloads in such cases by
> > default (to prevent simple silly mistakes from having possibly severe
> > consequences), but if a "force" option is used, we should regard that
> > as "the user really means it" and do as requested.  That would be very
> > much analogous to the hot-unplug situation from the software
> > perspective.
> 
> Sounds very reasonable to me.

I'm not so sure about this.  For one thing, how are you going to 
distinguish which module unloads are safe?

For another, even if you do make this distinction, don't you think 
people will get into the habit of always using the "force" option?  My 
impression is that most module unloads end up causing some device to be 
unbound from a driver, or even completely deregistered.

Right now the kernel uses the "You better know what you're doing when
you unload a module" point of view, and I don't see any good reasons
for changing.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/