[Toybox] pull: fix modprobe, login, switch_root, improve init, reboot

[Rob Landley]

On 10/01/2015 09:34 PM, Isaac Dunham wrote:
> On Thu, Oct 01, 2015 at 04:42:34AM -0500, Rob Landley wrote:
> (This was a preliminary patch that works for me but might not be
> appropriate for upstream.)

Indeed, but I'd like to get the functionality in which means
understanding it.

> modprobe $MODALIAS is the only thing this is expected to do.
> As far as I know (which is not very far), there are no cases where a single
> uevent calls for loading a module and creating a device.

I'd rather not preclude it though. The sysfs guys are notorious for
changing the meaning of everything they've done right up to the edge of
what Linus will smack them for.

> I suppose that it's improper to rely on that without finding docs;
> but it somehow seems wrong to do a fully blocking call to modprobe, and
> serially with that check if we need to create a device.

You're doing a fully blocking call to modeprobe anyway, xexec() will
have modeprobe inherit this pid (whether it's internal recursion or
execlp() the results't eh same), and that means this process won't exit
until modprobe does.

> Maybe (1) try to fork(); (2) if we succeed, xexec() modprobe; (3) do the
> whole mknod/chmod/... bit if appropriate; (4) on completion of that,
> call wait().

In theory devtmpfs can do the mknod for us. I'm _guessing_ that if
module insertion causes more devices to show up with more sysfs entries,
we'll get a separate event for that.

That said, why is blocking bad? The kernel can launch multiple
usermodehelper processes in parallel. (Ok, the netlink daemon version
might care, and I posted netlink code for this many moons ago at
http://lkml.iu.edu/hypermail/linux/kernel/0707.2/1085.html so I can
presumably add that any time...)

If you fork, why do you wait? (Who would you report failure _to_? Kernel
probably isn't going to care what your return code is. Maybe some sort
of log would, but right now we haven't got any logging infrastructure
and modprobe would probably be the one doing the logging if printk
didn't...)

> Note that a forkbomb, which could temporarily result in fork() failing,
> should not make the hotplugger die if it's long-running. Making module
> loading fail temporarily seems like it would be better.

Hence not calling xwrap() versions of things from daemons, hence wanting
maybe w prefixed versions that just warn, yes. I'm aware of this issue.

>> (I note that I have a todo item to implement demon mode doing the
>> netlink thing, in which case xexec() would again be the wrong thing...)
> 
> Agreed. But then, wouldn't xrun() also be the wrong thing?

If you mean "this runs a child process and waits for its return", I'm
not sure. If you mean "xwrap() can exit from daemon", yeah that's a
problem and it's part of the reason I did the toys.rebound stuff so
daemons can intercept xwrap() stuff. Assuming I can program the main
loops and such not to memory leak in that case.

(That whole area is an architectural todo item.)

> Thanks,
> Isaac Dunham

Rob

 1443784692.0