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

From: Alan Stern
Date: Mon Sep 21 2015 - 10:34:59 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/