Re: [PATCH] init/main.c: prevent warning on lack of default implicit rdinit

[Harry Austen]

On Thursday, 15 January 2026 at 02:47, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

> 
> 
> On Wed, 14 Jan 2026 22:02:27 +0000 Harry Austen hpausten@xxxxxxxxxxxxxx wrote:
> 
> > If rdinit was not explicitly provided on cmdline, and default /init does
> > not exist, no warning should be printed.
> > 
> > Fixes: 98aa4d5d242d ("init/main.c: add warning when file specified in rdinit is inaccessible")
> 
> 
> Details, please? What was wrong about the above commit?

The above commit introduced a warning regardless of whether rdinit execution
was actually wanted or not. If a system does not have the default /init file and
rdinit=* was not passed on the kernel cmdline, then it probably wasn't wanted.
This is the case on my personal system, i.e. after the above mentioned
commit, I now get the following logged by the kernel, at warning level:

check access for rdinit=/init failed: -2, ignoring

> 
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -162,6 +162,7 @@ static size_t initargs_offs;
> > 
> > static char *execute_command;
> > static char *ramdisk_execute_command = "/init";
> > +static bool __initdata ramdisk_execute_command_provided = false;
> > 
> > /*
> > * Used to generate warnings if static_key manipulation functions are used
> > @@ -623,6 +624,7 @@ static int __init rdinit_setup(char *str)
> > unsigned int i;
> > 
> > ramdisk_execute_command = str;
> > + ramdisk_execute_command_provided = true;
> > /* See "auto" comment in init_setup */
> > for (i = 1; i < MAX_INIT_ARGS; i++)
> > argv_init[i] = NULL;
> > @@ -1699,8 +1701,9 @@ static noinline void __init kernel_init_freeable(void)
> > int ramdisk_command_access;
> > ramdisk_command_access = init_eaccess(ramdisk_execute_command);
> > if (ramdisk_command_access != 0) {
> > - pr_warn("check access for rdinit=%s failed: %i, ignoring\n",
> > - ramdisk_execute_command, ramdisk_command_access);
> > + if (ramdisk_execute_command_provided || ramdisk_command_access != -ENOENT)
> > + pr_warn("check access for rdinit=%s failed: %i, ignoring\n",
> > + ramdisk_execute_command, ramdisk_command_access);
> 
> 
> Replacing the !=0 check with !=ENOENT appears to be off-topic. What's
> happening here?

Note that it wasn't _replaced_. I have added an _extra_ check for file existence.

Thanks for the review,
Harry