wait_for_initramfs warning from kernel_init_freeable()

wait_for_initramfs warning from kernel_init_freeable()

[Heiner Kallweit]

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()

Re: wait_for_initramfs warning from kernel_init_freeable()

[Heiner Kallweit]

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()

Re: wait_for_initramfs warning from kernel_init_freeable()

[Rasmus Villemoes]

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

Re: wait_for_initramfs warning from kernel_init_freeable()

[Heiner Kallweit]

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