mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Andrew Morton <akpm@linux-foundation.org>,
	 Alexander Potapenko <glider@google.com>,
	 Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Marco Elver <elver@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	 Dmitry Vyukov <dvyukov@google.com>,
	Vlastimil Babka <vbabka@kernel.org>,
	 John Ogness <john.ogness@linutronix.de>,
	Petr Mladek <pmladek@suse.com>,
	 kasan-dev@googlegroups.com, linux-mm@kvack.org,
	 linux-kernel@vger.kernel.org, kernel-team@meta.com,
	 Breno Leitao <leitao@debian.org>
Subject: [PATCH] stackdepot: don't WARN when the depot runs out of pools
Date: Tue, 03 Nov 2026 03:01:24 -0800	[thread overview]
Message-ID: <20261103-stackdepot-full-warn-v1-1-41f1fc651b64@debian.org> (raw)

depot_init_pool() emits WARN_ONCE() when the depot runs out of pools.
It runs with the raw pool_lock held and IRQs disabled, and
stack_depot_save_flags() wraps that section in printk_deferred_enter()
so that it does not print to the consoles with the lock held.

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. 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.

This was hit on an arm64 host running a KASAN and kmemleak enabled
linux-next kernel under stress-ng:

   Stack depot reached limit capacity
   WARNING: lib/stackdepot.c:302 at stack_depot_save_flags+0x6b0/0x6b8, CPU#56: stress-ng-dev/3466160
   smp: csd: Detected non-responsive CSD lock (#1) on CPU#66, waiting 5000000030 ns for CPU#19 do_nothing+0x0/0x18(0x0).
   smp: csd: Detected non-responsive CSD lock (#2) on CPU#4, waiting 5000000030 ns for CPU#61 ipi_mb+0x0/0x18(0x0).
   watchdog: CPU53: Watchdog detected hard LOCKUP on cpu 54
   Kernel panic - not syncing: Hard LOCKUP

The rest of the WARN splat never made it to the log: CPU 56 was still
flushing the console backlog from the "WARNING:" line when the hard
lockup detector fired.

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.

At normal priority the nbcon consoles are printed by the printer
threads, and the legacy consoles honour printk_deferred.

This also keeps a full depot from crashing machines running with
panic_on_warn.

Fixes: cd11016e5f52 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
 lib/stackdepot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 90c52f2e0d3f42..dea6338f73c1cd 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -299,7 +299,7 @@ static bool depot_init_pool(void **prealloc)
 		/* Bail out if we reached the pool limit. */
 		WARN_ON_ONCE(pools_num > stack_max_pools); /* should never happen */
 		WARN_ON_ONCE(!new_pool); /* to avoid unnecessary pre-allocation */
-		WARN_ONCE(1, "Stack depot reached limit capacity");
+		pr_warn_once("Stack depot reached limit capacity\n");
 		return false;
 	}
 

---
base-commit: 2637bdec0535a2044cd830eba9a79363651d9043
change-id: 20261103-stackdepot-full-warn-b29a9d89f1a5

Best regards,
--  
Breno Leitao <leitao@debian.org>


             reply	other threads:[~2026-11-03 11:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 11:01 Breno Leitao [this message]
2026-11-03 12:19 ` Marco Elver

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=20261103-stackdepot-full-warn-v1-1-41f1fc651b64@debian.org \
    --to=leitao@debian.org \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=john.ogness@linutronix.de \
    --cc=kasan-dev@googlegroups.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pmladek@suse.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=vbabka@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®