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

[Alan Stern]

On Tue, 22 Sep 2015, Rafael J. Wysocki wrote:

> On Monday, September 21, 2015 10:34:54 AM Alan Stern wrote:
> > 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?
> 
> Ones that have no dependencies?

Does a parent-child relationship count as a dependency?  AFAIK, that's 
the only sort of dependency we have for mounted filesystems, in 
general.

> Very simple: If the driver being unloaded is explicitly depended on by
> something (ie. there is a "device link" to it), we fail the unload with
> -EBUSY unless the "force" option is used.

Hmmm.  In other words, you will iterate through all the drivers,
checking the ->owner field against the module being removed.  Then for
each matching driver, you will iterate through all the bound devices,
and all their descendants, looking for links of the appropriate type.  
And perhaps do the same thing for subsystems and classes.

Doable, I guess, even if it is inelegant.  Fortunately module unload
has no timing requirements.

> > 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.
> 
> Well, is that point of view appropriate from the users' perspective?

I suspect people will find it more appropriate than the new point of
view you are proposing.  I don't know how often people unload modules,
but I suspect almost every time they do, it involves unregistering one
or more devices.  Goodness knows how many of those devices will be the
target of a dependency link, though.

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/