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.

Log the error code as well if we failed to open the console.

Signed-off-by: Yicong Yang <yang.yicong@picoheart.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();
 
 	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));
 		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();
 
 	/*
 	 * check if there is an early userspace init.  If yes, let it do all
-- 
2.34.1

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@picoheart.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.

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.

>  
>  	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?

>  		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?

thanks,

greg k-h

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@picoheart.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.