From: Steven Rostedt <rostedt@goodmis.org>
To: Andrew Halaney <ahalaney@redhat.com>
Cc: pmladek@suse.com, john.ogness@linutronix.de,
senozhatsky@chromium.org, debarbos@redhat.com,
williams@redhat.com, jlelli@redhat.com,
linux-rt-users@vger.kernel.org
Subject: Re: [BUG] printk/nbcon can use RCU illegally prior to CPU online
Date: Thu, 18 Jul 2024 16:17:34 -0400 [thread overview]
Message-ID: <20240718161734.3c2d3850@rorschach.local.home> (raw)
In-Reply-To: <qhv54n4limuh335borcwdnailiuecez3jlie35zoo7vgerix4q@cqtetxuc6a3b>
On Thu, 18 Jul 2024 14:34:41 -0500
Andrew Halaney <ahalaney@redhat.com> wrote:
> Heh, exactly why I made a "reproducer" for the printk/RCU side of the
> splat with linux-rt-devel before reporting.
>
> So my takeaway is that printk is not considered safe to use in all
> contexts, including during SMP bringup (because RCU's at play and not
> yet ready to be used on those CPUs). So if we do printk for reasons we
> can't control (say some firmware problem causing an exception) and try
> to print you could get the RCU warning about printk/nbcon usage in
> addition to the actual error, and that's just something to accept.
Well, in most cases people don't run a debug kernel in production and
if this printk was triggered in production, that warning would not show
up (it's only there when lockdep is enabled).
>
> Ideally though we don't printk() in those situations... so if its badly
> behaving code calling printk() that's a different story.
Right. printk() does get called in locations it shouldn't simply due to
a bug happening. But then, it's just a best effort to get information
to the user.
>
> Let me know if you think that recap is bogus.
I think you summarized it well.
-- Steve
next prev parent reply other threads:[~2024-07-18 20:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:41 [BUG] printk/nbcon can use RCU illegally prior to CPU online Andrew Halaney
2024-07-18 15:57 ` Steven Rostedt
2024-07-18 18:13 ` Andrew Halaney
2024-07-18 19:24 ` Steven Rostedt
2024-07-18 19:34 ` Andrew Halaney
2024-07-18 20:17 ` Steven Rostedt [this message]
2024-07-19 7:55 ` John Ogness
2024-07-19 14:09 ` Andrew Halaney
2024-07-19 14:55 ` John Ogness
2024-07-19 15:02 ` Andrew Halaney
2024-07-19 8:26 ` John Ogness
2024-07-19 16:01 ` Andrew Halaney
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=20240718161734.3c2d3850@rorschach.local.home \
--to=rostedt@goodmis.org \
--cc=ahalaney@redhat.com \
--cc=debarbos@redhat.com \
--cc=jlelli@redhat.com \
--cc=john.ogness@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=senozhatsky@chromium.org \
--cc=williams@redhat.com \
/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.