]> git.karo-electronics.de Git - karo-tx-linux.git/commitdiff
mm-more-intensive-memory-corruption-debug-fix
authorAndrew Morton <akpm@linux-foundation.org>
Fri, 2 Dec 2011 03:12:02 +0000 (14:12 +1100)
committerStephen Rothwell <sfr@canb.auug.org.au>
Tue, 6 Dec 2011 03:59:24 +0000 (14:59 +1100)
tweak documentation, s/flg/flag/

Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Documentation/kernel-parameters.txt
mm/page_alloc.c

index 8baea354a291f39360b5e92047e0a94b179100a5..e3bd3ffff013092862199e609909f44a526d3c34 100644 (file)
@@ -625,21 +625,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
        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
 
index d74b839b0a0f80dcd64a3655f5fcf2fa16283856..c231e2af56981c8edc06199e88269c33b8d9d01e 100644 (file)
@@ -441,18 +441,18 @@ static int __init debug_guardpage_minorder_setup(char *buf)
 }
 __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(struct page *page,
                 * 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 *zone, struct page *page,
                         * 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));