mm: more intensive memory corruption debug

PATCH In review Stanislaw Gruszka 5 participants 16 messages Nov 18, 2011 – Jan 6, 2012

Subsystems (7)

Memory management Documentation MM core Page allocator +3 more subsystems

lore

Share & tools

lore

Stanislaw Gruszka

author

2011-11-18 16:23 UTC #0 lore raw

PATCH v2 1/3 mm: more intensive memory corruption debug

With CONFIG_DEBUG_PAGEALLOC configured, cpu will generate exception on access (read,write) to not allocated page, what allow to catch code which corrupt memory. However kernel is trying to maximalise memory usage, hence there is usually not much free pages in the system and buggy code usually corrupt some crucial data.

This patch change buddy allocator to keep more free/protected pages and interlace free/protected and allocated pages to increase probability of catch a corruption.

When kernel is compiled with CONFIG_DEBUG_PAGEALLOC, debug_guardpage_minorder defines the minimum order used by the page allocator to grant a request. The requested size will be returned with the remaining pages used as guard pages.

v1 -> v2:
- change "corrupt" name to guard page
- document disability to debug memory corruption happened at bus level
- document max order limitation
- add comments about adding/removing guard pages from buddy allocator
- do not change types in expand()

Signed-off-by Stanislaw Gruszka <[email protected]>

---
 Documentation/kernel-parameters.txt |   18 ++++++++
 include/linux/mm.h                  |   17 ++++++++
 include/linux/page-debug-flags.h    |    4 +-
 mm/Kconfig.debug                    |    5 ++
 mm/page_alloc.c                     |   75 ++++++++++++++++++++++++++++++++---
 5 files changed, 112 insertions(+), 7 deletions(-)

Documentation/kernel-parameters.txt +18 -0

index a0c5c5f..92e2076 100644
@@ -623,6 +623,24 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 	no_debug_objects
 			[KNL] Disable object debugging
 
+	debug_guardpage_minorder=
+			[KNL] When CONFIG_DEBUG_PAGEALLOC is set, this
+			parameter allows control order of pages that will be
+			intentionally kept free (and hence protected) by buddy
+			allocator. Bigger value increase probability of
+			catching random memory corruption, but reduce amount
+			of memory for normal system use. Maximum possible
+			value is MAX_ORDER/2. Setting this parameter to 1 or 2,
+			should be enough to identify most random memory
+			corruption problems caused by bugs in kernel/drivers
+			code when CPU write to (or read from) random memory
+			location. Note that there exist class of memory
+			corruptions problems caused by buggy H/W or F/W or by
+			drivers badly programing DMA (basically when memory is
+			written at bus level and CPU MMU is bypassed), which
+			are not detectable by CONFIG_DEBUG_PAGEALLOC, hence this
+			option would not help tracking down these problems too.
+
 	debugpat	[X86] Enable PAT debugging
 
 	decnet.addr=	[HW,NET]

include/linux/mm.h +17 -0

index 0a22db1..90c3f69 100644
@@ -1617,5 +1617,22 @@ extern void copy_user_huge_page(struct page *dst, struct page *src,
 				unsigned int pages_per_huge_page);
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */
 
+#ifdef CONFIG_DEBUG_PAGEALLOC
+extern unsigned int _debug_guardpage_minorder;
+
+static inline unsigned int debug_guardpage_minorder(void)
+{
+	return _debug_guardpage_minorder;
+}
+
+static inline bool page_is_guard(struct page *page)
+{
+	return test_bit(PAGE_DEBUG_FLAG_GUARD, &page->debug_flags);
+}
+#else
+static inline unsigned int debug_guardpage_minorder(void) { return 0; }
+static inline bool page_is_guard(struct page *page) { return false; }
+#endif /* CONFIG_DEBUG_PAGEALLOC */
+
 #endif /* __KERNEL__ */
 #endif /* _LINUX_MM_H */

include/linux/page-debug-flags.h +3 -1

index b0638fd..22691f6 100644
@@ -13,6 +13,7 @@
 
 enum page_debug_flags {
 	PAGE_DEBUG_FLAG_POISON,		/* Page is poisoned */
+	PAGE_DEBUG_FLAG_GUARD,
 };
 
 /*

@@ -21,7 +22,8 @@ enum page_debug_flags {
  */
 
 #ifdef CONFIG_WANT_PAGE_DEBUG_FLAGS
-#if !defined(CONFIG_PAGE_POISONING) \
+#if !defined(CONFIG_PAGE_POISONING) && \
+    !defined(CONFIG_PAGE_GUARD) \
 /* && !defined(CONFIG_PAGE_DEBUG_SOMETHING_ELSE) && ... */
 #error WANT_PAGE_DEBUG_FLAGS is turned on with no debug features!
 #endif

mm/Kconfig.debug +5 -0

index 8b1a477..4b24432 100644
@@ -4,6 +4,7 @@ config DEBUG_PAGEALLOC
 	depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC
 	depends on !KMEMCHECK
 	select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC
+	select PAGE_GUARD if ARCH_SUPPORTS_DEBUG_PAGEALLOC
 	---help---
 	  Unmap pages from the kernel linear mapping after free_pages().
 	  This results in a large slowdown, but helps to find certain types

@@ -22,3 +23,7 @@ config WANT_PAGE_DEBUG_FLAGS
 config PAGE_POISONING
 	bool
 	select WANT_PAGE_DEBUG_FLAGS
+
+config PAGE_GUARD
+	bool
+	select WANT_PAGE_DEBUG_FLAGS

mm/page_alloc.c +69 -6

111 lines not on this page · raw message

Signature · 8 lines

1.7.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Stanislaw Gruszka

author

2011-11-18 16:23 UTC #1 lore raw

PATCH v2 2/3 PM / Hibernate : do not count debug pages as savable

When debugging with CONFIG_DEBUG_PAGEALLOC and debug_guardpage_minorder > 0, we have lot of free pages that are not marked so. Snapshot code account them as savable, what cause hibernate memory preallocation failure.

It is pretty hard to make hibernate allocation succeed with debug_guardpage_minorder=1. This change at least make it possible when system has relatively big amount of RAM.

v1 -> v2:
- change "corrupt" name to guard page

Acked-by Rafael J. Wysocki <[email protected]>

Signed-off-by Stanislaw Gruszka <[email protected]>

---
 kernel/power/snapshot.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

kernel/power/snapshot.c +6 -0

index cbe2c14..1cf8890 100644
@@ -858,6 +858,9 @@ static struct page *saveable_highmem_page(struct zone *zone, unsigned long pfn)
 	    PageReserved(page))
 		return NULL;
 
+	if (page_is_guard(page))
+		return NULL;
+
 	return page;
 }

@@ -920,6 +923,9 @@ static struct page *saveable_page(struct zone *zone, unsigned long pfn)
 	    && (!kernel_page_present(page) || pfn_is_nosave(pfn)))
 		return NULL;
 
+	if (page_is_guard(page))
+		return NULL;
+
 	return page;
 }

Signature · 8 lines

1.7.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Stanislaw Gruszka

author

2011-11-18 16:23 UTC #2 lore raw

PATCH v3 3/3 slub: min order when debug_guardpage_minorder > 0

In reply to Stanislaw Gruszka

Disable slub debug facilities and allocate slabs at minimal order when debug_guardpage_minorder > 0 to increase probability to catch random memory corruption by cpu exception.

v1 -> v2:
- use slub_max_order to minimalize slub order

Signed-off-by Stanislaw Gruszka <[email protected]>

---
 mm/slub.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

mm/slub.c +3 -0

index 7d2a996..a66be56 100644
@@ -3645,6 +3645,9 @@ void __init kmem_cache_init(void)
 	struct kmem_cache *temp_kmem_cache_node;
 	unsigned long kmalloc_size;
 
+	if (debug_guardpage_minorder())
+		slub_max_order = 0;
+
 	kmem_size = offsetof(struct kmem_cache, node) +
 				nr_node_ids * sizeof(struct kmem_cache_node *);

Signature · 8 lines

1.7.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Christoph Lameter

Acked-by on v3 3/3

2011-11-21 17:15 UTC #3 lore raw

Re: [PATCH v3 3/3] slub: min order when debug_guardpage_minorder > 0

Quoted 3 lines · Stanislaw Gruszka

Disable slub debug facilities and allocate slabs at minimal order when debug_guardpage_minorder > 0 to increase probability to catch random memory corruption by cpu exception.

Acked-by Christoph Lameter <[email protected]>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

David Rientjes

reviewer

2011-12-07 22:08 UTC #4 lore raw

Re: [PATCH v3 3/3] slub: min order when debug_guardpage_minorder > 0

In reply to Stanislaw Gruszka

Quoted 5 lines · Stanislaw Gruszka

mm/slub.c +0 -0

index 7d2a996..a66be56 100644

mm/slub.c void __init kmem_cache_init(void) · line 3653

Quoted 9 lines

mm/slub.c +3 -0

@@ -3645,6 +3645,9 @@ void __init kmem_cache_init(void)
 	struct kmem_cache *temp_kmem_cache_node;
 	unsigned long kmalloc_size;
 
+	if (debug_guardpage_minorder())
+		slub_max_order = 0;
+
 	kmem_size = offsetof(struct kmem_cache, node) +
 				nr_node_ids * sizeof(struct kmem_cache_node *);

I'd recommend at least printing a warning about why slub_max_order was reduced because users may be concerned why they can't now change any cache's order with /sys/kernel/slab/cache/order.

Stanislaw Gruszka

author

2011-12-08 07:33 UTC #5 lore raw

Re: [PATCH v3 3/3] slub: min order when debug_guardpage_minorder > 0

Quoted 10 lines · David Rientjes

Quoted 8 lines · Stanislaw Gruszka

mm/slub.c +0 -0

index 7d2a996..a66be56 100644
@@ -3645,6 +3645,9 @@ void __init kmem_cache_init(void)
 	struct kmem_cache *temp_kmem_cache_node;
 	unsigned long kmalloc_size;

Quoted 10 lines

mm/slub.c void __init kmem_cache_init(void) · line 3653
Quoted 6 lines
mm/slub.c +3 -0
+	if (debug_guardpage_minorder())
+		slub_max_order = 0;
+
 	kmem_size = offsetof(struct kmem_cache, node) +
 				nr_node_ids * sizeof(struct kmem_cache_node *);
 
I'd recommend at least printing a warning about why slub_max_order was reduced because users may be concerned why they can't now change any cache's order with /sys/kernel/slab/cache/order.

It's only happen with debug_guardpage_minorder=N parameter, so perhaps I'll just document that in kernel-parameters.txt

Thanks
Stanislaw

David Rientjes

reviewer

2011-12-08 21:06 UTC #6 lore raw

Re: [PATCH v3 3/3] slub: min order when debug_guardpage_minorder > 0

Quoted 19 lines · Stanislaw Gruszka

Quoted 8 lines
Quoted 8 lines
mm/slub.c +0 -0
index 7d2a996..a66be56 100644
@@ -3645,6 +3645,9 @@ void __init kmem_cache_init(void)
 	struct kmem_cache *temp_kmem_cache_node;
 	unsigned long kmalloc_size;
 
Quoted 10 lines
mm/slub.c void __init kmem_cache_init(void) · line 3653
Quoted 6 lines
mm/slub.c +3 -0
+	if (debug_guardpage_minorder())
+		slub_max_order = 0;
+
 	kmem_size = offsetof(struct kmem_cache, node) +
 				nr_node_ids * sizeof(struct kmem_cache_node *);
 
I'd recommend at least printing a warning about why slub_max_order was reduced because users may be concerned why they can't now change any cache's order with /sys/kernel/slab/cache/order.

Quoted 3 lines

It's only happen with debug_guardpage_minorder=N parameter, so perhaps I'll just document that in kernel-parameters.txt

SLUB will output a line in the dmesg that specifies the possible orders so it would be helpful to also note that those can change because of debug_guardpage_minorder in both Documentation/vm/slub.txt and the "order" file entry in Documentation/ABI/testing/sysfs-kernel-slab.

Thanks!

Stanislaw Gruszka

author

2011-12-12 14:59 UTC #7 lore raw

PATCH 1/1 slub: document setting min order with debug_guardpage_minorder > 0

Signed-off-by Stanislaw Gruszka <[email protected]>

---
English is hard (definitely harder than C language :-), so please correct me, if I wrote something wrong.

 Documentation/ABI/testing/sysfs-kernel-slab |    4 +++-
 Documentation/vm/slub.txt                   |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

Documentation/ABI/testing/sysfs-kernel-slab +3 -1

index 8b093f8..d84ca80 100644
@@ -345,7 +345,9 @@ Description:
 		allocated.  It is writable and can be changed to increase the
 		number of objects per slab.  If a slab cannot be allocated
 		because of fragmentation, SLUB will retry with the minimum order
-		possible depending on its characteristics.
+		possible depending on its characteristics. 
+		When debug_guardpage_minorder > 0 parameter is specified, the
+		minimum possible order is used and cannot be changed.
 
 What:		/sys/kernel/slab/cache/order_fallback
 Date:		April 2008

Documentation/vm/slub.txt +3 -1

index f464f47..dbf02ad 100644
@@ -131,7 +131,9 @@ slub_min_objects.
 slub_max_order specified the order at which slub_min_objects should no
 longer be checked. This is useful to avoid SLUB trying to generate
 super large order pages to fit slub_min_objects of a slab cache with
-large object sizes into one high order page.
+large object sizes into one high order page. Setting parameter
+debug_guardpage_minorder > 0 forces setting slub_max_order to 0, what
+cause minimum possible order of slabs allocation.
 
 SLUB Debug output
 -----------------

Signature · 8 lines

1.7.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rafael J. Wysocki

2011-12-12 23:18 UTC #8 lore raw

Re: [PATCH -mm] slub: document setting min order with debug_guardpage_minorder > 0

Quoted 14 lines · Stanislaw Gruszka

Signed-off-by Stanislaw Gruszka <[email protected]>
---
English is hard (definitely harder than C language :-), so please correct me, if I wrote something wrong.
 Documentation/ABI/testing/sysfs-kernel-slab |    4 +++-
 Documentation/vm/slub.txt                   |    4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)
Documentation/ABI/testing/sysfs-kernel-slab +0 -0
index 8b093f8..d84ca80 100644

Documentation/ABI/testing/sysfs-kernel-slab Description: · line 348

Quoted 5 lines

Documentation/ABI/testing/sysfs-kernel-slab +1 -1

@@ -345,7 +345,9 @@ Description:
 		allocated.  It is writable and can be changed to increase the
 		number of objects per slab.  If a slab cannot be allocated
 		because of fragmentation, SLUB will retry with the minimum order
-		possible depending on its characteristics.
+		possible depending on its characteristics.

Added trailing whitespace (please remove).

Documentation/ABI/testing/sysfs-kernel-slab Description: · line 350

Quoted 2 lines

Documentation/ABI/testing/sysfs-kernel-slab +2 -0

+		When debug_guardpage_minorder > 0 parameter is specified, the
+		minimum possible order is used and cannot be changed.

Well, I'm not sure what you wanted to say, actually? How does one change debug_guardpage_minorder (or specify it), for example? Is it a kernel command-line switch?

Also I'm not sure what "cannot be changed" is supposed to mean. Does it mean that /sys/cache/slab/cache/order has no effect in that case?

Quoted 9 lines

Documentation/ABI/testing/sysfs-kernel-slab +0 -0
 What:		/sys/kernel/slab/cache/order_fallback
 Date:		April 2008
Documentation/vm/slub.txt +0 -0
index f464f47..dbf02ad 100644

Documentation/vm/slub.txt slub_min_objects. · line 139

Quoted 10 lines

Documentation/vm/slub.txt +3 -1

@@ -131,7 +131,9 @@ slub_min_objects.
 slub_max_order specified the order at which slub_min_objects should no
 longer be checked. This is useful to avoid SLUB trying to generate
 super large order pages to fit slub_min_objects of a slab cache with
-large object sizes into one high order page.
+large object sizes into one high order page. Setting parameter
+debug_guardpage_minorder > 0 forces setting slub_max_order to 0, what
+cause minimum possible order of slabs allocation.
 
 SLUB Debug output
 -----------------

Rafael

David Rientjes

reviewer

2011-12-14 00:41 UTC #9 lore raw

Re: [PATCH -mm] slub: document setting min order with debug_guardpage_minorder > 0

Quoted 13 lines · Rafael J. Wysocki

Documentation/ABI/testing/sysfs-kernel-slab Description: · line 348
Quoted 10 lines
Documentation/ABI/testing/sysfs-kernel-slab +1 -1
index 8b093f8..d84ca80 100644
@@ -345,7 +345,9 @@ Description:
 		allocated.  It is writable and can be changed to increase the
 		number of objects per slab.  If a slab cannot be allocated
 		because of fragmentation, SLUB will retry with the minimum order
-		possible depending on its characteristics.
+		possible depending on its characteristics. 
Added trailing whitespace (please remove).

Quoted 7 lines

Documentation/ABI/testing/sysfs-kernel-slab Description: · line 350
Quoted 2 lines
Documentation/ABI/testing/sysfs-kernel-slab +2 -0
+		When debug_guardpage_minorder > 0 parameter is specified, the
+		minimum possible order is used and cannot be changed.
Well, I'm not sure what you wanted to say, actually? How does one change debug_guardpage_minorder (or specify it), for example? Is it a kernel command-line switch?

Yeah, we'll need a reference to Documentation/kernel-parameters.txt.

Quoted 3 lines

Also I'm not sure what "cannot be changed" is supposed to mean. Does it mean that /sys/cache/slab/cache/order has no effect in that case?

Good point, we should say that "this tunable" cannot be used to change the order at runtime if debug_guardpage_minorder is used on the command line.

Stanislaw, one more revision?

Stanislaw Gruszka

author

2011-12-16 13:22 UTC #10 lore raw

Re: [PATCH -mm] slub: document setting min order with debug_guardpage_minorder > 0

Quoted 10 lines · David Rientjes

Quoted 7 lines
Documentation/ABI/testing/sysfs-kernel-slab Description: · line 350
Quoted 2 lines
Documentation/ABI/testing/sysfs-kernel-slab +2 -0
+		When debug_guardpage_minorder > 0 parameter is specified, the
+		minimum possible order is used and cannot be changed.
Well, I'm not sure what you wanted to say, actually? How does one change debug_guardpage_minorder (or specify it), for example? Is it a kernel command-line switch?
Yeah, we'll need a reference to Documentation/kernel-parameters.txt.

Quoted 8 lines

Quoted 3 lines
Also I'm not sure what "cannot be changed" is supposed to mean. Does it mean that /sys/cache/slab/cache/order has no effect in that case?
Good point, we should say that "this tunable" cannot be used to change the order at runtime if debug_guardpage_minorder is used on the command line.
Stanislaw, one more revision?

Ehh, I silently hoped that someone else with better English skills could fix it ;-)

As Andrew already applied my patch (and fix whitespace) I'll post the incremental patch in the next e-mail.

Thanks
Stanislaw

Stanislaw Gruszka

author

2011-12-16 13:23 UTC #11 lore raw

PATCH 1/1 slub: debug_guardpage_minorder documentation tweak

Signed-off-by Stanislaw Gruszka <[email protected]>

---
 Documentation/ABI/testing/sysfs-kernel-slab |    6 ++++--
 Documentation/vm/slub.txt                   |    7 ++++---
 2 files changed, 8 insertions(+), 5 deletions(-)

Documentation/ABI/testing/sysfs-kernel-slab +4 -2

index bfd1d9f..91bd6ca 100644
@@ -346,8 +346,10 @@ Description:
 		number of objects per slab.  If a slab cannot be allocated
 		because of fragmentation, SLUB will retry with the minimum order
 		possible depending on its characteristics.
-		When debug_guardpage_minorder > 0 parameter is specified, the
-		minimum possible order is used and cannot be changed.
+		When debug_guardpage_minorder=N (N > 0) parameter is specified
+		(see Documentation/kernel-parameters.txt), the minimum possible
+		order is used and this sysfs entry can not be used to change
+		the order at run time.
 
 What:		/sys/kernel/slab/cache/order_fallback
 Date:		April 2008

Documentation/vm/slub.txt +4 -3

index dbf02ad..1514d9f 100644
@@ -131,9 +131,10 @@ slub_min_objects.
 slub_max_order specified the order at which slub_min_objects should no
 longer be checked. This is useful to avoid SLUB trying to generate
 super large order pages to fit slub_min_objects of a slab cache with
-large object sizes into one high order page. Setting parameter
-debug_guardpage_minorder > 0 forces setting slub_max_order to 0, what
-cause minimum possible order of slabs allocation.
+large object sizes into one high order page. Setting command line
+parameter debug_guardpage_minorder=N (N > 0), forces setting
+slub_max_order to 0, what cause minimum possible order of slabs
+allocation.
 
 SLUB Debug output
 -----------------

Signature · 8 lines

1.7.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

David Rientjes

reviewer Acked-by on v1 1/1

2011-12-16 21:16 UTC #12 lore raw

Re: [PATCH -mm] slub: debug_guardpage_minorder documentation tweak

Quoted 1 line · Stanislaw Gruszka

Signed-off-by Stanislaw Gruszka <[email protected]>

Acked-by David Rientjes <[email protected]>

Andrew, this should be folded into slub-document-setting-min-order-with-debug_guardpage_minorder-0.patch which should be folded into slub-min-order-when-debug_guardpage_minorder-0.patch

Thanks!

David Rientjes

reviewer

2012-01-06 17:53 UTC #13 lore raw

Re: [PATCH -mm] slub: debug_guardpage_minorder documentation tweak

Quoted 9 lines · David Rientjes

Quoted 1 line
Signed-off-by Stanislaw Gruszka <[email protected]>
Acked-by David Rientjes <[email protected]>
Andrew, this should be folded into slub-document-setting-min-order-with-debug_guardpage_minorder-0.patch which should be folded into slub-min-order-when-debug_guardpage_minorder-0.patch

Andrew, this documentation improvement is still missing from linux-next.

Andrew Morton

maintainer

2011-11-22 21:56 UTC #14 lore raw

In reply to Stanislaw Gruszka

Quoted 6 lines · On Fri, 18 Nov 2011 17:25:05 +0100 Stanislaw Gruszka <[email protected]>…

With CONFIG_DEBUG_PAGEALLOC configured, cpu will generate exception on access (read,write) to not allocated page, what allow to catch code which corrupt memory. However kernel is trying to maximalise memory usage, hence there is usually not much free pages in the system and buggy code usually corrupt some crucial data.

Quoted 9 lines

This patch change buddy allocator to keep more free/protected pages and interlace free/protected and allocated pages to increase probability of catch a corruption.
When kernel is compiled with CONFIG_DEBUG_PAGEALLOC, debug_guardpage_minorder defines the minimum order used by the page allocator to grant a request. The requested size will be returned with the remaining pages used as guard pages.

I added this:

The default value of debug_guardpage_minorder is zero: no change from current behaviour.

correct?

Quoted 8 lines

...

(quoted diff) +5 -0

+static int __init debug_guardpage_minorder_setup(char *buf)
+{
+	unsigned long res;
+
+	if (kstrtoul(buf, 10, &res) < 0 ||  res > MAX_ORDER / 2) {

Review

Quoted 10 lines

(quoted diff) +10 -0

+		printk(KERN_ERR "Bad debug_guardpage_minorder value\n");
+		return 0;
+	}
+	_debug_guardpage_minorder = res;
+	printk(KERN_INFO "Setting debug_guardpage_minorder to %lu\n", res);
+	return 0;
+}
+__setup("debug_guardpage_minorder=", debug_guardpage_minorder_setup);
+
+static inline void set_page_guard_flg(struct page *page)

"flag" not "flg", please ;)

Review

Quoted 8 lines

(quoted diff) +8 -0

+{
+	__set_bit(PAGE_DEBUG_FLAG_GUARD, &page->debug_flags);
+}
+
+static inline void clear_page_guard_flg(struct page *page)
+{
+	__clear_bit(PAGE_DEBUG_FLAG_GUARD, &page->debug_flags);
+}

Why is it safe to use the non-atomic bitops here.

Please verify that CONFIG_WANT_PAGE_DEBUG_FLAGS is always reliably enabled when this feature is turned on.

Quoted 3 lines

...

Some changes I made - please review.

 Documentation/kernel-parameters.txt |   31 +++++++++++++-------------
 mm/page_alloc.c                     |   12 +++++-----
 2 files changed, 22 insertions(+), 21 deletions(-)

Documentation/kernel-parameters.txt renamed from Documentation/kernel-parameters.txt~mm-more-intensive-memory-corruption-debug-fix +16 ~~-15~~

diff -puN Documentation/kernel-parameters.txt~mm-more-intensive-memory-corruption-debug-fix Documentation/kernel-parameters.txt
@@ -625,21 +625,22 @@ bytes respectively. Such letter suffixes
 
 	debug_guardpage_minorder=
 			[KNL] When CONFIG_DEBUG_PAGEALLOC is set, this
-			parameter allows control order of pages that will be
-			intentionally kept free (and hence protected) by buddy
-			allocator. Bigger value increase probability of
-			catching random memory corruption, but reduce amount
-			of memory for normal system use. Maximum possible
-			value is MAX_ORDER/2. Setting this parameter to 1 or 2,
-			should be enough to identify most random memory
-			corruption problems caused by bugs in kernel/drivers
-			code when CPU write to (or read from) random memory
-			location. Note that there exist class of memory
-			corruptions problems caused by buggy H/W or F/W or by
-			drivers badly programing DMA (basically when memory is
-			written at bus level and CPU MMU is bypassed), which
-			are not detectable by CONFIG_DEBUG_PAGEALLOC, hence this
-			option would not help tracking down these problems too.
+			parameter allows control of the order of pages that will
+			be intentionally kept free (and hence protected) by the
+			buddy allocator. Bigger value increase the probability
+			of catching random memory corruption, but reduce the
+			amount of memory for normal system use. The maximum
+			possible value is MAX_ORDER/2.  Setting this parameter
+			to 1 or 2 should be enough to identify most random
+			memory corruption problems caused by bugs in kernel or
+			driver code when a CPU writes to (or reads from) a
+			random memory location. Note that there exists a class
+			of memory corruptions problems caused by buggy H/W or
+			F/W or by drivers badly programing DMA (basically when
+			memory is written at bus level and the CPU MMU is
+			bypassed) which are not detectable by
+			CONFIG_DEBUG_PAGEALLOC, hence this option will not help
+			tracking down these problems.
 
 	debugpat	[X86] Enable PAT debugging

mm/page_alloc.c renamed from mm/page_alloc.c~mm-more-intensive-memory-corruption-debug-fix +6 -6

diff -puN mm/page_alloc.c~mm-more-intensive-memory-corruption-debug-fix mm/page_alloc.c
@@ -441,18 +441,18 @@ static int __init debug_guardpage_minord
 }
 __setup("debug_guardpage_minorder=", debug_guardpage_minorder_setup);
 
-static inline void set_page_guard_flg(struct page *page)
+static inline void set_page_guard_flag(struct page *page)
 {
 	__set_bit(PAGE_DEBUG_FLAG_GUARD, &page->debug_flags);
 }
 
-static inline void clear_page_guard_flg(struct page *page)
+static inline void clear_page_guard_flag(struct page *page)
 {
 	__clear_bit(PAGE_DEBUG_FLAG_GUARD, &page->debug_flags);
 }
 #else
-static inline void set_page_guard_flg(struct page *page) { }
-static inline void clear_page_guard_flg(struct page *page) { }
+static inline void set_page_guard_flag(struct page *page) { }
+static inline void clear_page_guard_flag(struct page *page) { }
 #endif
 
 static inline void set_page_order(struct page *page, int order)

@@ -578,7 +578,7 @@ static inline void __free_one_page(struc
 		 * merge with it and move up one order.
 		 */
 		if (page_is_guard(buddy)) {
-			clear_page_guard_flg(buddy);
+			clear_page_guard_flag(buddy);
 			set_page_private(page, 0);
 			__mod_zone_page_state(zone, NR_FREE_PAGES, 1 << order);
 		} else {

@@ -821,7 +821,7 @@ static inline void expand(struct zone *z
 			 * pages will stay not present in virtual address space
 			 */
 			INIT_LIST_HEAD(&page[size].lru);
-			set_page_guard_flg(&page[size]);
+			set_page_guard_flag(&page[size]);
 			set_page_private(&page[size], high);
 			/* Guard pages are not available for any usage */
 			__mod_zone_page_state(zone, NR_FREE_PAGES, -(1 << high));

Stanislaw Gruszka

author

2011-11-23 13:23 UTC #15 lore raw

Quoted 8 lines · Andrew Morton

On Fri, 18 Nov 2011 17:25:05 +0100
Stanislaw Gruszka <[email protected]> wrote:
I added this:
The default value of debug_guardpage_minorder is zero: no change from current behaviour.
correct?

Yes,

Quoted 6 lines

Review
Quoted 4 lines
(quoted diff) +4 -0
+static inline void clear_page_guard_flg(struct page *page)
+{
+	__clear_bit(PAGE_DEBUG_FLAG_GUARD, &page->debug_flags);
+}
Why is it safe to use the non-atomic bitops here.

Clearing/setting flag is done only in __free_one_page()/expand(), so operations are protected by zone->lock.

Quoted 2 lines

Please verify that CONFIG_WANT_PAGE_DEBUG_FLAGS is always reliably enabled when this feature is turned on.

Change in mm/Kconfig.debug assures that CONFIG_WANT_PAGE_DEBUG_FLAGS is set whenever CONFIG_DEBUG_PAGEALLOC is.

Quoted 1 line

Some changes I made - please review.

Look good, thanks Andrew!

Stanislaw