Re: [RFC] fs: add userspace critical mounts event support

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Wed, Nov 09, 2016 at 03:21:07AM -0800, Andy Lutomirski wrote:
> On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner
> <daniel.wagner@bmw-carit.de> wrote:
> > [CC: added Harald]
> >
> > As Harald pointed out over a beer yesterday evening, there is at least
> > one more reason why UMH isn't obsolete. The ordering of the firmware loading
> > might be of important. Say you want to greet the user with a splash screen
> > really early on, the graphic card firmware should be loaded first. Also the
> > automotive world has this fancy requirement that rear camera must be on the
> > screen within 2 seconds. So controlling the firmware loading order is of
> > importance (e.g. also do not overcommit the I/O bandwith not so important
> > firmwares). A user space helper is able to prioritize the request
> > accordingly the use case.
> 
> That seems like a valid problem, but I don't think that UMH adequately
> solves it.  Sure, loading firmware in the right order avoids a >2sec
> delay due to firmware loading, but what happens when you have a slow
> USB device that *doesn't* need firmware plugged in to your car's shiny
> USB port when you start the car?
> 
> It seems to me that this use case requires explicit control over
> device probing and, if that gets added, you get your firmware ordering
> for free (just probe the important devices first).

In theory this is correct, the problem comes with the flexibility we have
created with pivot_root() and friends (another is mount on /lib/firmware) which
enables system integrators to pick and choose the "real rootfs" to be a few
layers away from the first fs picked up by the kernel. In providing this
flexibility we did not envision nor have devised signals to enable a
deterministic lookup due to the requirements such lookups might have --
in this case the requirements are that direct fs is ready and kosher
all the paths possible for firmware are ready. As you can imagine first race is
not only an issue for firmware but a generic issue.

The generic race on the fs lookup requires a fs availability event, and
addressing fs suspend. I'll note that the race on init is addressed today
*only* by the firmware UMH (its UMH is kobject uevent and optionally a custom
binary) by using the UMH lock. During a cleanup by Daniel recently I
realized it was bogus to use the UMH of the UMH was not used, turns out
this would still expose the direct FS lookup to a race though. This
begs the question if the UMH lock either be removed / shared with the
other kernel UMHs or a generic solution provided for direct fs lookup
with some requirements specified.

This is all a mess so I've documented each component and issues / ideas
we've discussed so far separately, the firmware UMH (which we should
probably rebrand to firmware kobject uevent helper to avoid confusion)
[0], the real kernel usermode helper [1], the new common kernel file
loader [2]

[0] https://kernelnewbies.org/KernelProjects/firmware-class-enhancements
[1] https://kernelnewbies.org/KernelProjects/usermode-helper-enhancements
[2] https://kernelnewbies.org/KernelProjects/common-kernel-loader

  Luis