From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,rdunlap@infradead.org,corbet@lwn.net,catalin.marinas@arm.com,leitao@debian.org,akpm@linux-foundation.org
Subject: [merged mm-stable] documentation-kmemleak-describe-the-metadata-pool-not-the-early-log.patch removed from -mm tree
Date: Mon, 12 Oct 2026 21:32:57 -0700 [thread overview]
Message-ID: <20261013043257.8C7B71F00893@smtp.kernel.org> (raw)
The quilt patch titled
Subject: Documentation: kmemleak: describe the metadata pool, not the early log
has been removed from the -mm tree. Its filename was
documentation-kmemleak-describe-the-metadata-pool-not-the-early-log.patch
This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Breno Leitao <leitao@debian.org>
Subject: Documentation: kmemleak: describe the metadata pool, not the early log
Date: Thu, 17 Sep 2026 06:47:35 -0700
Patch series "kmemleak: fix stale documentation and raise the verbose
default".
The first two patches fix statements in
Documentation/dev-tools/kmemleak.rst that do not match mm/kmemleak.c.
The third requires one more consecutive unreferenced scan before a
CONFIG_DEBUG_KMEMLEAK_VERBOSE kernel reports a leak on the console, to
avoid the last false positives I am seeing when running
CONFIG_DEBUG_KMEMLEAK_VERBOSE on a daily basis.
This patch (of 3):
commit c5665868183f ("mm: kmemleak: use the memory pool for early
allocations") removed the early log buffer in favour of a static pool of
kmemleak_object structures, but the documentation still describes the old
mechanism.
Fix the documentation by describing what the pool actually is, matching
the Kconfig help text.
Link: https://lore.kernel.org/20260917142210.90829-1-sj@kernel.org
Link: https://lore.kernel.org/20260917-b4-kmemleak-doc-v1-1-84fde6d1f749@debian.org
Fixes: c5665868183f ("mm: kmemleak: use the memory pool for early allocations")
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Randy Dunlap <rdunlap@infradead.org>
---
Documentation/dev-tools/kmemleak.rst | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/Documentation/dev-tools/kmemleak.rst~documentation-kmemleak-describe-the-metadata-pool-not-the-early-log
+++ a/Documentation/dev-tools/kmemleak.rst
@@ -66,9 +66,14 @@ Memory scanning parameters can be modifi
Kmemleak can also be disabled at boot-time by passing ``kmemleak=off`` on
the kernel command line.
-Memory may be allocated or freed before kmemleak is initialised and
-these actions are stored in an early log buffer. The size of this buffer
-is configured via the CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE option.
+Memory may be allocated or freed before kmemleak is initialised, so a
+static pool of metadata objects is used to track those allocations. Once
+kmemleak is fully initialised the pool becomes an emergency reserve, used
+whenever a metadata object cannot be allocated from the slab. The number
+of objects in the pool is configured via the
+CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE option. Exhausting it at run time
+prints "Cannot allocate a kmemleak_object structure" and disables
+kmemleak.
If CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF are enabled, the kmemleak is
disabled by default. Passing ``kmemleak=on`` on the kernel command
_
Patches currently in -mm which might be from leitao@debian.org are
reply other threads:[~2026-10-13 4:32 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261013043257.8C7B71F00893@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=leitao@debian.org \
--cc=mm-commits@vger.kernel.org \
--cc=rdunlap@infradead.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.