Messages in this thread | | | From | Heiner Kallweit <> | Subject | Re: wait_for_initramfs warning from kernel_init_freeable() | Date | Thu, 29 Apr 2021 10:52:16 +0200 |
| |
On 29.04.2021 10:18, Rasmus Villemoes wrote: > 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: >
Thanks for the prompt response. Yes, that's the config here:
CONFIG_UEVENT_HELPER=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
I now disabled CONFIG_UEVENT_HELPER and don't have the warning any longer. Maybe, what could be done so that you don't have to explain the same thing a hundred times to people like me:
In case the warning is harmless, make it info or notice and add a hint like this to the message "please reconsider whether you really need config option CONFIG_UEVENT_HELPER".
> 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 >
Heiner
| |