linux-kernel - Re: [PATCH printk v1 07/10] console: add write

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: <YS2aBeymxuiW3CIw@google.com>
Date:   Tue, 31 Aug 2021 11:55:01 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Petr Mladek <pmladek@...e.com>,
        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>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Vitor Massaru Iha <vitor@...saru.org>,
        Sedat Dilek <sedat.dilek@...il.com>,
        Changbin Du <changbin.du@...el.com>
Subject: Re: [PATCH printk v1 07/10] console: add write_atomic interface

On (21/08/03 15:18), John Ogness wrote:
[..]
> @@ -1993,6 +1993,16 @@ static int console_trylock_spinning(void)
>  	bool spin = false;
>  	unsigned long flags;
>  
> +#ifdef CONFIG_SMP
> +	/*
> +	 * CPUs holding the printk cpulock must not spin on any lock. Even
> +	 * console_trylock() must not be called because its implementation
> +	 * uses spinlocks.
> +	 */
> +	if (atomic_read(&printk_cpulock_owner) == smp_processor_id())
> +		return 0;
> +#endif
> +
>  	if (console_trylock())
>  		return 1;
>  
> @@ -2719,7 +2729,17 @@ static int have_callable_console(void)
>   */
>  static inline int can_use_console(void)
>  {
> -	return cpu_online(raw_smp_processor_id()) || have_callable_console();
> +	int cpu = raw_smp_processor_id();
> +#ifdef CONFIG_SMP
> +	/*
> +	 * CPUs holding the printk cpulock must not spin on any lock.
> +	 * Allowing console usage could call into the spinlocks of the
> +	 * various console drivers.
> +	 */
> +	if (atomic_read(&printk_cpulock_owner) == cpu)
> +		return 0;

I guess the only reason this is done in can_use_console() is
console_flush_on_panic()?

Because otherwise, I think, we can move this check to vprintk_emit().

can_use_console() can be called from preemptible() context. But
if it's called from preemptible() then we know that this is not
printk()/NMI path (but console_device() and friends instead) and
that this CPU is definitely not holding printk CPU lock.

console_trylock_spinning() and console_unlock()->can_use_console()
follow each other

	if (console_trylock_spinning())
		console_unlock();

so a single `atomic_read(&printk_cpulock_owner) == cpu` can suffice.

Now we get to the console_flush_on_panic(), which still calls console_unlock(),
iterates over messages, but when called by the CPU that owns printk_lock,
just skips all the messages. But there is no point in calling console_unlock()
in such a case, we can check if we're printk_cpulock_owner and bail out if so.

Or am I missing something?