linux-kernel - Re: [PATCH 2/2] init: Move console_on_rootfs after async_synchronize

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: <6969336d-3c26-4a21-ac44-d620b549f278@picoheart.com>
Date: Thu, 22 Jan 2026 21:12:24 +0800
From: "Yicong Yang" <yang.yicong@...oheart.com>
To: "Greg KH" <gregkh@...uxfoundation.org>
Cc: <yang.yicong@...oheart.com>, <rafael@...nel.org>, <lenb@...nel.org>, 
	<tglx@...nel.org>, <dakr@...nel.org>, <akpm@...ux-foundation.org>, 
	<apatel@...tanamicro.com>, <pjw@...nel.org>, <palmer@...belt.com>, 
	<aou@...s.berkeley.edu>, <alex@...ti.fr>, <geshijian@...oheart.com>, 
	<weidong.wd@...oheart.com>, <linux-acpi@...r.kernel.org>, 
	<linux-kernel@...r.kernel.org>, <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH 2/2] init: Move console_on_rootfs after async_synchronize_full

On 1/22/26 6:27 PM, Greg KH wrote:
> On Thu, Jan 22, 2026 at 03:34:46PM +0800, Yicong Yang wrote:
>> Currently the console_on_rootfs() is called before
>> async_synchronize_full(), the console initialization
>> could be still in process in theory due to async
>> probe, etc. Make it after the async_synchronize_full()
>> to make sure the initialization work is done.
> 
> Please wrap at 72 columns.
> 
>>
>> Log the error code as well if we failed to open the console.
>>
>> Signed-off-by: Yicong Yang <yang.yicong@...oheart.com>
>> ---
>>  init/main.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/init/main.c b/init/main.c
>> index b84818ad9685..c37ba5f89b96 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -1578,6 +1578,7 @@ static int __ref kernel_init(void *unused)
>>  	kernel_init_freeable();
>>  	/* need to finish all async __init code before freeing the memory */
>>  	async_synchronize_full();
>> +	console_on_rootfs();
> 
> Are you sure this is ok?  Messing around with init levels and order is
> _VERY_ tricky.
> 

It's previously in kernel_init_freeable() after do_basic_setup() (where
initcalls invoked). So moving it here the init levels and order is
unchanged (still after the do_basic_setup).

Tested with initrd (ramdisk) and initramfs made by busybox and works fine
(hope no other scenarios missed).


> Your console should NOT be on an async probe path, if you really need
> it, then do not do that at all.  Make it sync, and then it should be ok.
> 

not for my console. it's a theoretical issue during the last discussion but
I did try to make this happened (by make the probe async and add some delay
in the probe to simulate a slow initialization).

since indeed no real problem I met and if consider it should never happen in
real case, should we just leave it as is?

>>  
>>  	system_state = SYSTEM_FREEING_INITMEM;
>>  	kprobe_free_init_mem();
>> @@ -1647,7 +1648,7 @@ void __init console_on_rootfs(void)
>>  	struct file *file = filp_open("/dev/console", O_RDWR, 0);
>>  
>>  	if (IS_ERR(file)) {
>> -		pr_err("Warning: unable to open an initial console.\n");
>> +		pr_err("Warning: unable to open an initial console, err = %ld\n", PTR_ERR(file));
> 
> Why is this changed?
> 

This is a trivial change so I didn't make a separate patch. I suppose it's
useful since I did see different errors (ENOENT, ENODEV) when make cases
for testing this patch and we've already have the err code returned here.

>>  		return;
>>  	}
>>  	init_dup(file);
>> @@ -1690,7 +1691,6 @@ static noinline void __init kernel_init_freeable(void)
>>  	kunit_run_all_tests();
>>  
>>  	wait_for_initramfs();
>> -	console_on_rootfs();
> 
> You just delayed the console output for many (i.e. most) systems out
> there, are you sure that is acceptable to them?
> 

IIUC, console_on_rootfs() will open /dev/console for userspace's
stdout/stdin/stderr and kernel log (printk, etc) won't be affected
by its order.

Thanks.