[Toybox] [PATCH] losetup: Wait for ueventd to create loop device on Android

[enh]

On Wed, Aug 24, 2022 at 1:13 AM Rob Landley <rob at landley.net> wrote:

> Applied the patch, but WOW this is conceptually ugly...
>
> On 8/23/22 10:57, Yi-yo Chiang via Toybox wrote:> Android doesn't use
> devtmpfs.
>
> Huh, I thought Android was using it because you guys got blamed for
> shoehorning
> userspace policy into the kernel back in 2013:
>
> https://lwn.net/Articles/548477/#:~:text=devtmpfs
>
> (The kernel having infrastructure to know that gid 44 is "video" and
> needing an
> /etc/groups that matches is kinda creepy. Yet another thing Kay Sievers
> advocated and Greg KH endorsed before Linus threw Kay out of kernel
> development
> and he went off to do systemd full time...)
>
> Do you think Android is likely to start using devtmpfs at some point in the
> future?


TL;DR: no, i don't.

although i don't directly work on that stuff (and dvander is more likely to
have a canonical answer), i know a lot of people have _hoped_ to use it and
looked at it over the years, but i don't think it's fit for purpose? the
problem (ironically, given your complaint) is that it doesn't know _enough_
about the system. so it's racy and init has to run around after it fixing
up the stuff (like selinux labels) that it _doesn't_ set. (iirc it didn't
even do regular unix permissions right?) so if init's got to do _some_ of
the work, init may as well do _all_ of the work so there's no window where
you can see a "half-finished" node.

I didn't know there were any systems left doing hotplug without it.
> There are some deeply embedded ones with a static /dev that never hotplug
> anything, but those same systems often don't have /proc and /sys mounted
> either.
> One of the few patches I still bother to send to lkml from time to time is
> https://lkml.iu.edu/hypermail/linux/kernel/2201.2/00174.html because I'm
> using
> it locally. I still have mdev on the toybox todo list because it's
> basically
> hotplugd, but it moved WAY down the priority list and am not likely to
> keep the
> original mknod behavior in a final version because devtmpfs happened.
>
> > Instead device nodes under /dev are
> > created by userspace daemon ueventd. There could be a noticeable delay
> > between LOOP_CTL_GET_FREE issued and loop device created, so we need to
> > wait until it is created and then continue.
>
> With devtmpfs the device node is guaranteed to have been created before
> returning to userspace, although you can still race with the hotplug
> notifier if
> the creator and a daemon both try to respond to the device showing up.
> (Both the
> the usermodehelper plumbing and the netlink socket will _dispatch_ before
> the
> syscall returns, but the scheduler can do what it likes with different
> processes...)
>
> And yes, I read through kernel code at one point to work this out. :P
>
> > The timeout (5s) and time quantum (20ms) is picked randomly, it bares no
> > special meaning but they worked fine empirically.
>
> As I said, applied. All the ugly here is conceptual: there's no way to make
> "this should not be happening" pretty.
>
> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220824/c1aa2d70/attachment.htm>