From: Heiner Kallweit <hkallweit1@gmail.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Luis Chamberlain <mcgrof@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: wait_for_initramfs warning from kernel_init_freeable()
Date: Thu, 29 Apr 2021 10:52:16 +0200 [thread overview]
Message-ID: <9849be80-cfe5-b33e-8224-590a4c451415@gmail.com> (raw)
In-Reply-To: <45556f52-cd2f-5512-ba65-81e4acee21ff@rasmusvillemoes.dk>
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
prev parent reply other threads:[~2021-04-29 8:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-29 6:46 wait_for_initramfs warning from kernel_init_freeable() Heiner Kallweit
2021-04-29 7:16 ` Heiner Kallweit
2021-04-29 8:18 ` Rasmus Villemoes
2021-04-29 8:52 ` Heiner Kallweit [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9849be80-cfe5-b33e-8224-590a4c451415@gmail.com \
--to=hkallweit1@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mcgrof@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).