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: <Yg9gMEGDZlF/+DH2@alley>
Date:   Fri, 18 Feb 2022 10:00:32 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: early start: was: Re: [PATCH printk v1 10/13] printk: add kthread
 console printers

On Mon 2022-02-07 20:49:20, John Ogness wrote:
> Create a kthread for each console to perform console printing. During
> normal operation (@system_state == SYSTEM_RUNNING), the kthread
> printers are responsible for all printing on their respective
> consoles.
> 
> During non-normal operation, console printing is done as it has been:
> within the context of the printk caller or within irq work triggered
> by the printk caller.
> 
> Console printers synchronize against each other and against console
> lockers by taking the console lock for each message that is printed.
> ---
>  include/linux/console.h |   2 +
>  kernel/printk/printk.c  | 159 +++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 159 insertions(+), 2 deletions(-)
> 
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -373,6 +380,14 @@ void printk_direct_exit(void)
>  	atomic_dec(&printk_direct);
>  }
>  
> +static inline bool allow_direct_printing(void)
> +{
> +	return (!kthreads_started ||
> +		system_state != SYSTEM_RUNNING ||

It would be great to use printk kthreads as early as possible.

I have seen many soft-lockups when the system initialized
many devices, for example, many disks or network interfaces.
I am not completely sure. But I think that it might happen
already when initcalls are proceed.

Many messages might be printed when people are debugging
something.

kthreads are usable when "kthreadd" kernel thread is started in
rest_init(). It means that they might be usable also in
SYSTEM_SCHEDULING and SYSTEM_FREEING_INITMEM.

> +		oops_in_progress ||
> +		atomic_read(&printk_direct));
> +}
> +
>  DECLARE_WAIT_QUEUE_HEAD(log_wait);
>  /* All 3 protected by @syslog_lock. */
>  /* the next printk record to read by syslog(READ) or /proc/kmsg */
> @@ -3275,6 +3313,13 @@ static int __init printk_late_init(void)
>  	ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "printk:online",
>  					console_cpu_notify, NULL);
>  	WARN_ON(ret < 0);
> +
> +	console_lock();
> +	for_each_console(con)
> +		start_printk_kthread(con);
> +	kthreads_started = true;
> +	console_unlock();

I would do this in core_initcall() so that the kthreads are used as
early as possible.

> +
>  	return 0;
>  }
>  late_initcall(printk_late_init);

Best Regards,
Petr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ