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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
