linux-um.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marcos Paulo de Souza <mpdesouza@suse.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	John Ogness	 <john.ogness@linutronix.de>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	Jason Wessel	 <jason.wessel@windriver.com>,
	Daniel Thompson <danielt@kernel.org>,
	Douglas Anderson <dianders@chromium.org>,
	Richard Weinberger <richard@nod.at>,
	Anton Ivanov	 <anton.ivanov@cambridgegreys.com>,
	Johannes Berg <johannes@sipsolutions.net>,
		linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
		kgdb-bugreport@lists.sourceforge.net,
	linux-um@lists.infradead.org
Subject: Re: [PATCH 2/7] printk: Use consoles_suspended flag when suspending/resuming all consoles
Date: Mon, 23 Jun 2025 15:53:14 -0300	[thread overview]
Message-ID: <d4f7a4dd5bedf288d2011fc9817716b8af2ec032.camel@suse.com> (raw)
In-Reply-To: <aExBo-8cVOy6GegR@pathway.suse.cz>

On Fri, 2025-06-13 at 17:20 +0200, Petr Mladek wrote:
> On Fri 2025-06-06 23:53:44, Marcos Paulo de Souza wrote:
> 
> 
> Variant C:
> ==========
> 
> Remove even @flags parameter from console_is_usable() and read both
> values there directly.
> 
> Many callers read @flags only because they call console_is_usable().
> The change would simplify the code.
> 
> But there are few exceptions:
> 
>   1. __nbcon_atomic_flush_pending(), console_flush_all(),
>      and legacy_kthread_should_wakeup() pass @flags to
>      console_is_usable() and also check CON_NBCON flag.
> 
>      But CON_NBCON flag is special. It is statically initialized
>      and never set/cleared at runtime. It can be checked without
>      READ_ONCE(). Well, we still might want to be sure that
>      the struct console can't disappear.
> 
>      IMHO, this can be solved by a helper function:
> 
> 	/**
> 	 * console_srcu_is_nbcon - Locklessly check whether the
> console is nbcon
> 	 * @con:	struct console pointer of console to check
> 	 *
> 	 * Requires console_srcu_read_lock to be held, which implies
> that @con might
> 	 * be a registered console. The purpose of holding
> console_srcu_read_lock is
> 	 * to guarantee that no exit/cleanup routines will run if
> the console
> 	 * is currently undergoing unregistration.
> 	 *
> 	 * If the caller is holding the console_list_lock or it is
> _certain_ that
> 	 * @con is not and will not become registered, the caller
> may read
> 	 * @con->flags directly instead.
> 	 *
> 	 * Context: Any context.
> 	 * Return: True when CON_NBCON flag is set.
> 	 */
> 	static inline bool console_is_nbcon(const struct console
> *con)
> 	{
> 		WARN_ON_ONCE(!console_srcu_read_lock_is_held());
> 
> 		/*
> 		 * The CON_NBCON flag is statically initialized and
> is never
> 		 * set or cleared at runtime.
> 		return data_race(con->flags & CON_NBCON);
> 	}
> 
> 
>    2. Another exception is __pr_flush() where console_is_usable() is
>       called twice with @use_atomic set "true" and "false".
> 
>       We would want to read "con->flags" only once here. A solution
>       would be to add a parameter to check both con->write_atomic
>       and con->write_thread in a single call.
> 
>       But it might actually be enough to check is with the "false"
>       value because "con->write_thread()" is mandatory for nbcon
>       consoles. And legacy consoles do not distinguish atomic mode.
> 

I like this idea. Also, thanks a lot for explaining why the current
version won't work.

I also liked John's proposal to use a a bitmask on console_is_usable,
but I'll think a little on it once I restart working on it this week.

> 
> My opinion:
> ===========
> 
> I personally prefer the variant C because:
> 
>   + Removes one parameter from console_is_usable().
> 
>   + The lockless synchronization of both global and per-console
>     flags is hidden in console_is_usable().
> 
>   + The global console_suspended flag will be stored in global
>     variable (in compare with variant D).
> 
> What do you think, please?

Much better, I'll adapt the code as you suggested.

> 
> Best Regards,
> Petr
> 
> 
> PS: The commit message and the cover letter should better explain
>     the background of this change.
> 
>     It would be great if the cover letter described the bigger
>     picture, especially the history of the console_suspended,
>     CON_SUSPENDED, and CON_ENABLED flags. It might use info
>     from
>     https://lore.kernel.org/lkml/ZyoNZfLT6tlVAWjO@pathway.suse.cz/
>     and maybe even this link.
> 
>     Also this commit message should mention that it partly reverts
>     the commit 9e70a5e109a4a233678 ("printk: Add per-console
>     suspended state"). But it is not simple revert because
>     we need to preserve the synchronization using
>     the console_list_lock for writing and SRCU for reading.

I agree, such a context would even help the reviewers that would spend
some time reading the code and thinking themselves that some code is
being readded for some reason.



  parent reply	other threads:[~2025-06-24  0:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-07  2:53 [PATCH 0/7] printk cleanup - part 2 Marcos Paulo de Souza
2025-06-07  2:53 ` [PATCH 1/7] printk: Make console_{suspend,resume} handle CON_SUSPENDED Marcos Paulo de Souza
2025-06-12 11:46   ` Petr Mladek
2025-06-23 18:45     ` Marcos Paulo de Souza
2025-06-07  2:53 ` [PATCH 2/7] printk: Use consoles_suspended flag when suspending/resuming all consoles Marcos Paulo de Souza
2025-06-13 15:20   ` Petr Mladek
2025-06-20 14:43     ` John Ogness
2025-06-24  8:40       ` Petr Mladek
2025-06-24 11:04         ` John Ogness
2025-06-25  8:48           ` Petr Mladek
2025-06-23 18:53     ` Marcos Paulo de Souza [this message]
2025-06-07  2:53 ` [PATCH 3/7] drivers: tty: Check CON_SUSPENDED instead of CON_ENABLED Marcos Paulo de Souza
2025-06-12 11:48   ` Petr Mladek
2025-06-07  2:53 ` [PATCH 4/7] drivers: serial: kgdboc: " Marcos Paulo de Souza
2025-06-09 20:13   ` Doug Anderson
2025-06-10 20:03     ` Marcos Paulo de Souza
2025-06-10 23:18       ` Doug Anderson
2025-06-12 13:57         ` Petr Mladek
2025-06-12 23:16           ` Doug Anderson
2025-06-13 10:52             ` Petr Mladek
2025-06-13 16:44               ` Doug Anderson
2025-06-07  2:53 ` [PATCH 5/7] arch: um: kmsg_dump: Don't check for CON_ENABLED Marcos Paulo de Souza
2025-06-16 13:33   ` Petr Mladek
2025-06-20 15:45     ` John Ogness
2025-06-07  2:53 ` [PATCH 6/7] debug: kgd_io: " Marcos Paulo de Souza
2025-06-16 13:56   ` Petr Mladek
2025-06-30  0:31     ` Marcos Paulo de Souza
2025-06-07  2:53 ` [PATCH 7/7] printk: Don't check for CON_ENABLED on console_unblank Marcos Paulo de Souza
2025-06-16 14:02   ` Petr Mladek
2025-06-17  9:32     ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d4f7a4dd5bedf288d2011fc9817716b8af2ec032.camel@suse.com \
    --to=mpdesouza@suse.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=danielt@kernel.org \
    --cc=dianders@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jason.wessel@windriver.com \
    --cc=jirislaby@kernel.org \
    --cc=johannes@sipsolutions.net \
    --cc=john.ogness@linutronix.de \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=pmladek@suse.com \
    --cc=richard@nod.at \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).