Re: [PATCH] stackdepot: don't WARN when the depot runs out of pools

[Petr Mladek <pmladek@suse.com>]

On Wed 2026-11-04 09:26:55, John Ogness wrote:
> On 2026-11-03, Breno Leitao <leitao@debian.org> wrote:
> > That deferral only applies to legacy consoles. ON nbcon WARN() puts the
> > CPU in emergency mode, and in emergency mode printk() flushes all
> > pending records to the nbcon consoles from the calling context.
> 
> Yes. WARN() is supposed to be for critical issues.

I thought whether it is fine that NBCON consoles ignored printk
deferred context. I could imagine that WARN() is used just to
generate the backtrace but the message itself is not that critical.

Well, it was added to the stackdepot code by the commit a914d8d6cf204287aa
("lib/stackdepot: add printk_deferred_enter/exit guards"). And the
reason was to avoid deadlocks in the console code. And the deadlock
is prevented in the NBCON code by using try_lock approach. So that
NBCON consoles do not need to be deferred to prevent deadlocks.

And if anyone wants a less critical backtrace then we should introduce
another API for this, e.g. INFO().

> > With
> > a slow serial console (pl011 is an nbcon console) and a backlog of
> > messages, that flush can outlast the hard lockup threshold, all of it
> > with pool_lock held and IRQs disabled, while every other CPU that needs
> > to save a new stack trace spins on pool_lock.
> 
> Several serial drivers call touch_nmi_watchdog() (such as 8250) to avoid
> this issue. Perhaps the pl011 should be doing this as well (at least for
> the write_atomic() path)?

I agree that it would make sense.

> > Running out of depot space is an expected condition under heavy debug
> > load, not a kernel bug, so report it with pr_warn_once() instead.
> 
> This is the key takeaway. WARN() is not appropriate here.

I agree:

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr