while debugging a memory management problem it helped a lot to
get a system dump as early as possible for bad page states.
Lets assume that if panic_on_oops is set then the system should
not continue with broken mm data structures.
Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com>
---
mm/memory.c | 2 ++
mm/page_alloc.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 2c3536c..bdbf9cc 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -696,6 +696,8 @@ static void print_bad_pte(struct vm_area_struct *vma,
unsigned long addr,
printk(KERN_ALERT "vma->vm_file->f_op->mmap: %pSR\n",
vma->vm_file->f_op->mmap);
dump_stack();
+ if (panic_on_oops)
+ panic("Fatal exception");
add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8e20f9c..8c19db3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -337,6 +337,8 @@ static void bad_page(struct page *page, const char *reason,
print_modules();
dump_stack();
+ if (panic_on_oops)
+ panic("Fatal exception");
out:
/* Leave bad fields for debug, except PageBuddy could make trouble */
page_mapcount_reset(page); /* remove PageBuddy */
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
