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: 29+ 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-27 12:32 ` David Hildenbrand (Arm)
2026-04-27 14:10 ` Sasha Levin
2026-04-27 15:40 ` David Hildenbrand (Arm)
2026-04-27 18:56 ` Sasha Levin
2026-04-27 19:37 ` David Hildenbrand (Arm)
2026-04-27 23:24 ` Sasha Levin
2026-04-28 7:22 ` David Hildenbrand (Arm)
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 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.