Messages in this thread | | | Subject | Re: wait_for_initramfs warning from kernel_init_freeable() | From | Rasmus Villemoes <> | Date | Thu, 29 Apr 2021 10:18:50 +0200 |
| |
On 29/04/2021 09.16, Heiner Kallweit wrote: > On 29.04.2021 08:46, Heiner Kallweit wrote: >> Since 97f8172f9a98 ("init/initramfs.c: do unpacking asynchronously") I get >> the following warning early in the boot process from umh: >> "wait_for_initramfs() called before rootfs_initcalls" >> Some debugging lead me to the following call chain: >> >> kernel_init_freeable() >> -> do_basic_setup() >> -> driver_init() >> -> platform_bus_init() >> -> bus_register() >> -> kset_register() >> -> kobject_uvent() >> > > Sorry, this is the first umh call, but at this time UMH_DISABLED is still set. > The first umh call where UMH is enabled is the following: > > kernel_init_freeable() > -> do_basic_setup() > -> do_initcalls() > -> do_one_initcall() > -> wq_sysfs_init() <- core_initcall() > -> subsys_virtual_register() > -> bus_register() >
Thanks for the report. Do you have CONFIG_UEVENT_HELPER=y and CONFIG_UEVENT_HELPER_PATH set to a non-empty string? Assuming yes:
I did notice that on backporting those patches to an old BSP of ours, but the other platforms I had done those patches for didn't have UEVENT_HELPER set, so didn't know about until about a week ago.
Emitting calls to /sbin/hotplug before the initramfs has had a chance to begin being unpacked is a complete waste of cycles (it's a _lot_ of kernel threads being forked only to fail with -ENOENT because there's no such binary, or any other fs contents for that matter). Just keeping CONFIG_UEVENT_HELPER set but clearing CONFIG_UEVENT_HELPER_PATH (if actually needed, userspace can set it appropriately later) made booting quite noticably faster on that old and slow cpu.
So in a sense, that warning has served its purpose: drawing attention to a deficiency in the boot process (at least with such a .config).
A few options:
(1) Do nothing, have people reconsider whether they really need UEVENT_HELPER_PATH set.
(2) Move the usermodehelper_enable() call from do_basic_setup() to around rootfs_initcall time. Perhaps in populate_rootfs() itself, right after scheduling do_populate_rootfs(). And a similar call would need to be added in default_rootfs() in noinitramfs.c for the CONFIG_BLK_DEV_INITRD=n case. Or a separate rootfs_initcall() in kernel/umh.c itself, if we can rely on link order to put that after populate_rootfs.
I think (2) would eliminate the warning, but then the very first uevent from some random device probe will cause that wait_for_initramfs(), i.e. it will effectively end up making the initramfs unpacking synchronous for anybody with CONFIG_UEVENT_HELPER_PATH!="". I can live with that, of course, but OTOH it's a bit sad that they'd never have a way to know that they could boot faster by eliminating a legacy setting from their .config.
Rasmus
| |