From: Petr Mladek <pmladek@suse.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Marcos Paulo de Souza <mpdesouza@suse.com>,
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>,
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 4/7] drivers: serial: kgdboc: Check CON_SUSPENDED instead of CON_ENABLED
Date: Fri, 13 Jun 2025 12:52:35 +0200 [thread overview]
Message-ID: <aEwC81RhvveGP73Y@pathway.suse.cz> (raw)
In-Reply-To: <CAD=FV=WFWviPPR6VWmsN2-+vzRDoU6oTNH=EP6z1usG4EDR3+w@mail.gmail.com>
On Thu 2025-06-12 16:16:09, Doug Anderson wrote:
> Hi,
>
> On Thu, Jun 12, 2025 at 6:57 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > > > > > @@ -577,7 +577,8 @@ static int __init kgdboc_earlycon_init(char
> > > > > > *opt)
> > > > > > console_list_lock();
> > > > > > for_each_console(con) {
> > > > > > if (con->write && con->read &&
> > > > > > - (con->flags & (CON_BOOT | CON_ENABLED)) &&
> > > > > > + (con->flags & CON_BOOT) &&
> > > > > > + ((con->flags & CON_SUSPENDED) == 0) &&
> > > > >
> > > > > I haven't tried running the code, so I could easily be mistaken,
> > > > > but...
> > > > >
> > > > > ...the above doesn't seem like the correct conversion. The old
> > > > > expression was:
> > > > >
> > > > > (con->flags & (CON_BOOT | CON_ENABLED))
> > > > >
> > It is easy to get confused by the register_console() code. And
> > it has been even worse some years ago.
> >
> > Anyway, the current code sets CON_ENABLED for all registered
> > consoles, including CON_BOOT consoles. The flag is cleared only
> > by console_suspend()[*] or unregister_console().
> >
> > IMHO, kgdboc_earlycon_init() does not need to care about
> > console_suspend() because the kernel could not be suspended
> > during boot. Does this makes sense?
>
> Yeah, makes sense to me.
>
> > Resume:
> >
> > I would remove the check of CON_ENABLED or CON_SUSPENDED
> > from kgdboc_earlycon_init() completely.
> >
> > IMHO, we should keep the check of CON_BOOT because we do not
> > want to register "normal" console drivers as kgdboc_earlycon_io_ops.
> > It is later removed by kgdboc_earlycon_deinit(). I guess
> > that the code is not ready to handle a takeover from normal
> > to normal (even the same) console driver.
>
> I'm not sure I understand your last sentence there. In general the
> code handling all of the possible handoff (or lack of handoff) cases
> between kgdboc_earlycon and regular kgdboc is pretty wacky. At one
> point I thought through it all and tried to test as many scenarios as
> I could and I seem to remember trying to model some of the behavior on
> how earlycon worked. If something looks broken here then let me know.
Later update: The code is safe. The scenario below does not exist,
see the "WAIT:" section below.
I am not familiar with the kgdb init code. I thought about the
following scenario:
1. kgdboc_earlycon_init() registers some struct console via
kgdboc_earlycon_io_ops.cons = con;
pr_info("Going to register kgdb with earlycon '%s'\n", con->name);
if (kgdb_register_io_module(&kgdboc_earlycon_io_ops) != 0) {
and sets
earlycon_orig_exit = con->exit;
con->exit = kgdboc_earlycon_deferred_exit;
2. Later, configure_kgdboc() would find some "preferred" console
and register it via
for_each_console_srcu(cons) {
int idx;
if (cons->device && cons->device(cons, &idx) == p &&
idx == tty_line) {
kgdboc_io_ops.cons = cons;
[...]
err = kgdb_register_io_module(&kgdboc_io_ops);
, where kgdb_register_io_module would call deinit for the
previously registered kgdboc_earlycon_io_ops:
if (old_dbg_io_ops) {
old_dbg_io_ops->deinit();
return 0;
}
, where kgdboc_earlycon_deinit() might call the .exit() callback
kgdboc_earlycon_io_ops.cons->exit(kgdboc_earlycon_io_ops.cons);
BANG: If both "kgdboc_earlycon_io_ops" and "kgdboc_io_ops" pointed to
the same struct console then this might call .exit() callback
for a console which is still being used.
But I am wrong, see below.
WAIT:
I have got all the pieces together when writing this mail).
I see that the code is safe, namely:
static void kgdboc_earlycon_deinit(void)
{
if (!kgdboc_earlycon_io_ops.cons)
return;
if (kgdboc_earlycon_io_ops.cons->exit == kgdboc_earlycon_deferred_exit)
/*
* kgdboc_earlycon is exiting but original boot console exit
* was never called (AKA kgdboc_earlycon_deferred_exit()
* didn't ever run). Undo our trap.
*/
kgdboc_earlycon_io_ops.cons->exit = earlycon_orig_exit;
else if (kgdboc_earlycon_io_ops.cons->exit)
/*
* We skipped calling the exit() routine so we could try to
* keep using the boot console even after it went away. We're
* finally done so call the function now.
*/
kgdboc_earlycon_io_ops.cons->exit(kgdboc_earlycon_io_ops.cons);
kgdboc_earlycon_io_ops.cons = NULL;
}
It calls kgdboc_earlycon_io_ops.cons->exit() only when
unregister_console() tried to call the original con->exit()
which was reassigned to kgdboc_earlycon_deferred_exit()...
Updated resume:
It looks to me that even normal console can be used by
kgdboc_earlycon_io_ops and we could remove even the check
of the CON_BOOT flag.
My expectation:
If a "struct console" is registered then the driver is used
by printk() and it should be safe even for kgdboc_earlycon,
as long as it has both "con->write" and "con->read" callbacks.
So the check in kgdboc_earlycon_init() might be:
for_each_console(con) {
if (con->write && con->read &&
(!opt || !opt[0] || strcmp(con->name, opt) == 0))
break;
}
Heh, I hope that you were able to follow my thoughts and I did not
create even bigger confusion.
Best Regards,
Petr
next prev parent reply other threads:[~2025-06-13 11:31 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
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 [this message]
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=aEwC81RhvveGP73Y@pathway.suse.cz \
--to=pmladek@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=mpdesouza@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).