From: Breno Leitao <leitao@debian.org>
To: John Ogness <john.ogness@linutronix.de>
Cc: Marco Elver <elver@google.com>, Petr Mladek <pmladek@suse.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
Dmitry Vyukov <dvyukov@google.com>,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
kernel-team@meta.com
Subject: Re: [PATCH v2] kcsan: Don't enter an nbcon emergency section for verbose reports
Date: Wed, 4 Nov 2026 06:33:30 -0800 [thread overview]
Message-ID: <autB8IxyWgtaH_oE@gmail.com> (raw)
In-Reply-To: <87v76cahn2.fsf@jogness.linutronix.de>
On Wed, Nov 04, 2026 at 01:52:41PM +0106, John Ogness wrote:
> On 2026-11-04, Breno Leitao <leitao@debian.org> wrote:
> > Since commit 59cd94ef8009 ("lockdep: Mark emergency sections in lockdep
> > splats"), print_irqtrace_events() runs inside an nbcon emergency
> > section. It is not only used by lockdep splats, though: verbose KCSAN
> > reports call it too, and a data race report is not an emergency. Yet in
> > an emergency section, every printk() flushes all pending records to the
> > nbcon consoles from the calling context, instead of leaving them to the
> > printk threads.
>
> Wouldn't the below diff be the proper fix?
>
> John
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index c3dc84a7cef26..71f1b4b8f06d5 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -4245,8 +4245,6 @@ void print_irqtrace_events(struct task_struct *curr)
> {
> const struct irqtrace_events *trace = &curr->irqtrace;
>
> - nbcon_cpu_emergency_enter();
> -
> printk("irq event stamp: %u\n", trace->irq_events);
> printk("hardirqs last enabled at (%u): [<%px>] %pS\n",
> trace->hardirq_enable_event, (void *)trace->hardirq_enable_ip,
> @@ -4260,8 +4258,6 @@ void print_irqtrace_events(struct task_struct *curr)
> printk("softirqs last disabled at (%u): [<%px>] %pS\n",
> trace->softirq_disable_event, (void *)trace->softirq_disable_ip,
> (void *)trace->softirq_disable_ip);
> -
> - nbcon_cpu_emergency_exit();
> }
>
> static int HARDIRQ_verbose(struct lock_class *class)
> @@ -5797,8 +5793,11 @@ static noinstr void check_flags(unsigned long flags)
> }
> #endif
>
> - if (!debug_locks)
> + if (!debug_locks) {
> + nbcon_cpu_emergency_enter();
> print_irqtrace_events(current);
> + nbcon_cpu_emergency_exit();
> + }
>
> instrumentation_end();
> #endif
Yes, but it was unclear to me what were the invocations of
print_irqtrace_events() that needed the emergency turned on.
how did you decided that only check_flags() needed it?
Thanks for the review,
--breno
next prev parent reply other threads:[~2026-11-04 14:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 11:32 [PATCH v2] kcsan: Don't enter an nbcon emergency section for verbose reports Breno Leitao
2026-11-04 12:46 ` John Ogness
2026-11-04 14:33 ` Breno Leitao [this message]
2026-11-04 14:42 ` John Ogness
2026-11-05 9:59 ` Petr Mladek
2026-11-05 10:39 ` Breno Leitao
2026-11-05 10:59 ` John Ogness
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=autB8IxyWgtaH_oE@gmail.com \
--to=leitao@debian.org \
--cc=boqun@kernel.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=john.ogness@linutronix.de \
--cc=kasan-dev@googlegroups.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=will@kernel.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.