[lkml]   [2021]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: wait_for_initramfs warning from kernel_init_freeable()
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
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

(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

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


 \ /
  Last update: 2021-04-29 10:20    [W:0.045 / U:3.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site