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 10:52 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.