Re: [PATCH printk v1 03/13] printk: use percpu flag instead of cpu_online()

From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Petr Mladek <pmladek@suse.com>
Cc: John Ogness <john.ogness@linutronix.de>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH printk v1 03/13] printk: use percpu flag instead of cpu_online()
Date: Mon, 14 Feb 2022 16:08:35 +0900	[thread overview]
Message-ID: <Ygn/8yNrHnZEomJy@google.com> (raw)
In-Reply-To: <YgaJZtY+EH9JIGyo@alley>

On (22/02/11 17:05), Petr Mladek wrote:
> I dug more into the history to be more confident about the change.
> I am not sure that it is safe.
> 
> CON_ANYTIME really seems to be related to per-CPU variables and early
> boot, see the commit 76a8ad293912cd2f01eca ("[PATCH] Make printk work
> for really early debugging").

Hmm... This looks a bit tricky. It seems that the commit in question
is concerned with per-CPU variables access indeed; not printk() per-CPU
access though but per-CPU access from con->write(). I guess console_unlock()
did not use to access per-CPU variables before, it does now, so that
can_use_console() in fact protects both printk (which certainly happens)
and con->write() (do we even have it?) per-CPU access

	console_unlock()
	{
		if (!can_use_console())
			return;

		for (;;) {
			printk_safe_enter_irqsave() -> __this_cpu()

			printk_safe_exit_irqrestore() -> __this_cpu()
		}
	}