From: Sasha Levin <sashal@kernel.org>
To: akpm@linux-foundation.org, david@kernel.org, corbet@lwn.net
Cc: ljs@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org,
rppt@kernel.org, surenb@google.com, mhocko@suse.com,
skhan@linuxfoundation.org, jackmanb@google.com,
hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Sasha Levin <sashal@nvidia.com>,
Sanif Veeras <sveeras@nvidia.com>,
"Claude:claude-opus-4-7" <noreply@anthropic.com>
Subject: [RFC 3/7] mm: add Kconfig options for page consistency checker
Date: Fri, 24 Apr 2026 10:00:52 -0400 [thread overview]
Message-ID: <20260424140056.2094777-4-sashal@kernel.org> (raw)
In-Reply-To: <20260424140056.2094777-1-sashal@kernel.org>
From: Sasha Levin <sashal@nvidia.com>
Add two configuration options for the dual-bitmap page consistency
checker.
DEBUG_PAGE_CONSISTENCY enables the feature itself. It depends on
DEBUG_KERNEL since this is a debugging tool, and selects DEBUG_FS to
provide the statistics interface. Memory overhead is two bits per
physical page frame across two bitmaps, so about 1 MB for a 16 GB
system. The bitmaps are statically sized at boot from memblock, so
memory hotplug is not supported and the option depends on
!MEMORY_HOTPLUG.
DEBUG_PAGE_CONSISTENCY_PANIC controls the response to a detected
violation. When enabled (the default) the kernel panics on
double-alloc, double-free, or bitmap corruption; when disabled it
logs a warning and continues.
Based-on-patch-by: Sanif Veeras <sveeras@nvidia.com>
Assisted-by: Claude:claude-opus-4-7 <noreply@anthropic.com>
Signed-off-by: Sasha Levin <sashal@nvidia.com>
---
mm/Kconfig.debug | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 59 insertions(+)
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 7638d75b27db..a005c904677c 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -144,6 +144,65 @@ config PAGE_TABLE_CHECK_ENFORCED
If unsure say "n".
+config DEBUG_PAGE_CONSISTENCY
+ bool "Debug page allocator with dual-bitmap consistency checking"
+ depends on DEBUG_KERNEL
+ depends on !MEMORY_HOTPLUG
+ select DEBUG_FS
+ help
+ Enable dual-bitmap tracking of page allocations for corruption
+ detection. Uses two complementary bitmaps where the invariant
+ (primary == ~secondary) must hold. Any bit flip in either bitmap
+ will be detected.
+
+ This is useful for safety-critical systems requiring Freedom From
+ Interference (FFI) guarantees per ISO 26262 (ASIL-D) and IEC 61508
+ (SIL-3).
+
+ When disabled, the hooks compile away. When enabled, a static key
+ gates tracking until initialization succeeds. The bitmaps are flat,
+ covering the entire PFN range from memblock_start_of_DRAM() to
+ memblock_end_of_DRAM() including any holes. This is deliberate:
+ simple (pfn - min_pfn) indexing is trivially auditable and avoids
+ auxiliary data structures that could themselves be subject to
+ corruption. Memory overhead is two bits per PFN in the spanned
+ range, e.g. ~4 MB total for a 64 GB system. Waste from holes is
+ typically under 2%.
+
+ Based on NVIDIA safety research.
+
+ If unsure, say N.
+
+config DEBUG_PAGE_CONSISTENCY_PANIC
+ bool "Panic on page consistency failure"
+ depends on DEBUG_PAGE_CONSISTENCY
+ default y
+ help
+ If enabled, the kernel will panic when a page consistency
+ violation is detected, such as double-alloc or double-free.
+
+ If disabled, a WARN with a stack trace is emitted and execution
+ continues.
+
+ For safety-critical systems, say Y.
+ For debugging/development, say N.
+
+config DEBUG_PAGE_CONSISTENCY_KUNIT_TEST
+ tristate "KUnit tests for dual-bitmap consistency primitives" if !KUNIT_ALL_TESTS
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+ help
+ Enable KUnit tests for the dual-bitmap primitives defined in
+ <linux/dual_bitmap.h>. These tests verify the core algorithm:
+ setting and clearing bits in complementary bitmaps, detecting
+ double-set and double-clear conditions, and detecting simulated
+ corruption.
+
+ The tests exercise only the header-only dual_bitmap library and
+ do not require CONFIG_DEBUG_PAGE_CONSISTENCY.
+
+ If unsure, say N.
+
config PAGE_POISONING
bool "Poison pages after freeing"
help
--
2.53.0
next prev parent reply other threads:[~2026-04-24 14:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 14:00 [RFC 0/7] mm: dual-bitmap page allocator consistency checker Sasha Levin
2026-04-24 14:00 ` [RFC 1/7] mm: add generic dual-bitmap consistency primitives Sasha Levin
2026-04-24 14:00 ` [RFC 2/7] mm: add page consistency checker header Sasha Levin
2026-04-24 14:00 ` Sasha Levin [this message]
2026-04-24 14:00 ` [RFC 4/7] mm: add page consistency checker implementation Sasha Levin
2026-04-24 14:25 ` David Hildenbrand (Arm)
2026-04-24 14:49 ` Sasha Levin
2026-04-24 15:06 ` Pasha Tatashin
2026-04-24 18:28 ` David Hildenbrand (Arm)
2026-04-24 23:34 ` Sasha Levin
2026-04-25 5:30 ` David Hildenbrand (Arm)
2026-04-25 16:38 ` Sasha Levin
2026-04-24 18:26 ` David Hildenbrand (Arm)
2026-04-24 14:00 ` [RFC 5/7] mm/page_alloc: integrate page consistency hooks Sasha Levin
2026-04-24 14:00 ` [RFC 6/7] Documentation/mm: add page consistency checker documentation Sasha Levin
2026-04-24 14:00 ` [RFC 7/7] mm/page_consistency: add KUnit tests for dual-bitmap primitives Sasha Levin
2026-04-24 15:34 ` [RFC 0/7] mm: dual-bitmap page allocator consistency checker Matthew Wilcox
2026-04-24 15:53 ` Sasha Levin
2026-04-24 15:42 ` Vlastimil Babka (SUSE)
2026-04-24 16:25 ` Sasha Levin
2026-04-25 5:51 ` David Hildenbrand (Arm)
2026-04-25 16:09 ` Sasha Levin
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=20260424140056.2094777-4-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=noreply@anthropic.com \
--cc=rppt@kernel.org \
--cc=sashal@nvidia.com \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=sveeras@nvidia.com \
--cc=vbabka@kernel.org \
--cc=ziy@nvidia.com \
/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