Re: [PATCH] kcsan: Don't flush the consoles while holding report_lock

[Breno Leitao <leitao@debian.org>]

Hello John,

On Wed, Nov 04, 2026 at 11:57:32AM +0106, John Ogness wrote:
> On 2026-11-03, 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. In an emergency section, every printk() flushes all pending
> > records to the nbcon consoles from the calling context (instead of the
> > printk thread).
> >
> > With CONFIG_KCSAN_VERBOSE, print_report() calls print_irqtrace_events()
> > while holding the raw report_lock with interrupts disabled, so every
> > verbose report writes out the whole console backlog under report_lock,
> > as consoles/UARTs are usually slow, this is not good.
> 
> I am fine with this patch, but am not happy about the motivation. You
> are right that it is "not good", but it is "not good" because the CPU is
> being put into an emergency state when it is not really an
> emergency. Even if the report_lock was not being held, this patch would
> be equally valid.

Agreed. A KCSAN report is not an emergency, so it should not enter an
emergency section in the first place. report_lock only made the problem
visible, by turning the console flush into a hard lockup.

I will reword the commit message around that in v2.

> I would even say this patch fixes 59cd94ef8009 because
> print_irqtrace_events() is not exclusively used for lockdep splats.

Makes sense, I will add:

  Fixes: 59cd94ef8009 ("lockdep: Mark emergency sections in lockdep splats")

Thanks for the review,
--breno