Re: [PATCH printk v2] printk: Postpone kthread startup

[Derek Barbosa <debarbos@redhat.com>]

On Fri, Oct 16, 2026 at 11:00:34AM +0206, John Ogness wrote:
> There have been various bug reports related to SMP systems hanging
> on boot. The reports vary but seem to have some overlap with regard
> to missed IPI's during SMP setup. The reports also show that
> reverting NBCON console usage allows the bugs to disappear.
> 
> The NBCON kthreads for console printing are started very early
> during boot using early_initcall(). Since these kthreads are
> asynchronously enabling/disabling interrupts during early boot, they
> may be interfering with early SMP setup on some hardware platforms.
> 
> Starting the console printing kthreads later has shown to avoid the
> hanging on systems that could previously reproduce the issue.
> 
> Postpone kthread starting until after all arch initcalls have
> completed.
> 
> Reported-by: Derek Barbosa <debarbos@redhat.com>
> Closes: https://lore.kernel.org/linux-rt-users/arPmYPbFLf2EldIl@debarbos-thinkpadt14gen5.rmtusma.csb
> Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads")
> Signed-off-by: John Ogness <john.ogness@linutronix.de>
> ---
>  v1: https://lore.kernel.org/lkml/87ecdrqfhw.fsf@jogness.linutronix.de
> 
>  changes since v1:
>  - Reword commit message.
>  - Rebase from 6.6-rt to 7.3-rc.
> 
>  kernel/printk/printk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 0ed86b5e8b160..9a205f94bfac7 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -3864,7 +3864,7 @@ static int __init printk_set_kthreads_ready(void)
>  
>  	return 0;
>  }
> -early_initcall(printk_set_kthreads_ready);
> +subsys_initcall(printk_set_kthreads_ready);
>  #endif /* CONFIG_PRINTK */
>  
>  static int __read_mostly keep_bootcon;
> 
> base-commit: 38dfd607b58b63b5488d5756786ee4ee499eebb8
> -- 
> 2.47.3
> 

In the v1 thread, I mentioned that I would leave the reproducer spinning in the
test environment for a few more hours. It has been well over 9 hours. No signs
of the existing issue popping up.

Tested-by: Derek Barbosa <debarbos@redhat.com>

-- 
Derek <debarbos@redhat.com>