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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <GdMmea0ApWRILytU2urC6buaR7cLlS8rEqjEHhFUq8YxM-PTThbdEjXvLWLvGrdM9uPhddDdE4oey9I7BAtQu1v3QtMsLjX13dWP2egORlo=@protonmail.com>
Date: Thu, 15 Jan 2026 07:32:14 +0000
From: Harry Austen <hpausten@...tonmail.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Huacai Chen <chenhuacai@...nel.org>, linux-kernel@...r.kernel.org, Lillian Berry <lillian@...r-ark.net>
Subject: Re: [PATCH] init/main.c: prevent warning on lack of default implicit rdinit

On Thursday, 15 January 2026 at 02:47, Andrew Morton <akpm@...ux-foundation.org> wrote:

> 
> 
> On Wed, 14 Jan 2026 22:02:27 +0000 Harry Austen hpausten@...tonmail.com 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