Skip to content

Commit b234ed6

Browse files
Villemoestorvalds
authored andcommitted
init: move usermodehelper_enable() to populate_rootfs()
Currently, usermodehelper is enabled right before PID1 starts going through the initcalls. However, any call of a usermodehelper from a pure_, core_, postcore_, arch_, subsys_ or fs_ initcall is futile, as there is no filesystem contents yet. Up until commit e7cb072 ("init/initramfs.c: do unpacking asynchronously"), such calls, whether via some request_module(), a legacy uevent "/sbin/hotplug" notification or something else, would just fail silently with (presumably) -ENOENT from kernel_execve(). However, that commit introduced the wait_for_initramfs() synchronization hook which must be called from the usermodehelper exec path right before the kernel_execve, in order that request_module() et al done from *after* rootfs_initcall() time (i.e. device_ and late_ initcalls) would continue to find a populated initramfs as they used to. Any call of wait_for_initramfs() done before the unpacking has been scheduled (i.e. before rootfs_initcall time) must just return immediately [and let the caller find an empty file system] in order not to deadlock the machine. I mistakenly thought, and my limited testing confirmed, that there were no such calls, so I added a pr_warn_once() in wait_for_initramfs(). It turns out that one can indeed hit request_module() as well as kobject_uevent_env() during those early init calls, leading to a user-visible warning in the kernel log emitted consistently for certain configurations. We could just remove the pr_warn_once(), but I think it's better to postpone enabling the usermodehelper framework until there is at least some chance of finding the executable. That is also a little more efficient in that a lot of work done in umh.c will be elided. However, it does change the error seen by those early callers from -ENOENT to -EBUSY, so there is a risk of a regression if any caller care about the exact error value. Link: https://lkml.kernel.org/r/[email protected] Fixes: e7cb072 ("init/initramfs.c: do unpacking asynchronously") Signed-off-by: Rasmus Villemoes <[email protected]> Reported-by: Alexander Egorenkov <[email protected]> Reported-by: Bruno Goncalves <[email protected]> Reported-by: Heiner Kallweit <[email protected]> Cc: Luis Chamberlain <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
1 parent 1e1c158 commit b234ed6

File tree

3 files changed

+4
-1
lines changed

3 files changed

+4
-1
lines changed

init/initramfs.c

+2
Original file line numberDiff line numberDiff line change
@@ -15,6 +15,7 @@
1515
#include <linux/mm.h>
1616
#include <linux/namei.h>
1717
#include <linux/init_syscalls.h>
18+
#include <linux/umh.h>
1819

1920
static ssize_t __init xwrite(struct file *file, const char *p, size_t count,
2021
loff_t *pos)
@@ -727,6 +728,7 @@ static int __init populate_rootfs(void)
727728
{
728729
initramfs_cookie = async_schedule_domain(do_populate_rootfs, NULL,
729730
&initramfs_domain);
731+
usermodehelper_enable();
730732
if (!initramfs_async)
731733
wait_for_initramfs();
732734
return 0;

init/main.c

-1
Original file line numberDiff line numberDiff line change
@@ -1392,7 +1392,6 @@ static void __init do_basic_setup(void)
13921392
driver_init();
13931393
init_irq_proc();
13941394
do_ctors();
1395-
usermodehelper_enable();
13961395
do_initcalls();
13971396
}
13981397

init/noinitramfs.c

+2
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,7 @@
1010
#include <linux/kdev_t.h>
1111
#include <linux/syscalls.h>
1212
#include <linux/init_syscalls.h>
13+
#include <linux/umh.h>
1314

1415
/*
1516
* Create a simple rootfs that is similar to the default initramfs
@@ -18,6 +19,7 @@ static int __init default_rootfs(void)
1819
{
1920
int err;
2021

22+
usermodehelper_enable();
2123
err = init_mkdir("/dev", 0755);
2224
if (err < 0)
2325
goto out;

0 commit comments

Comments
 (0)