linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm: trigger panic on bad page or PTE states if panic_on_oops
@ 2015-03-16  8:37 Christian Borntraeger
  2015-03-16 11:00 ` Kirill A. Shutemov
  0 siblings, 1 reply; 6+ messages in thread
From: Christian Borntraeger @ 2015-03-16  8:37 UTC (permalink / raw)
  To: linux-mm; +Cc: linux-kernel, Christian Borntraeger

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 <borntraeger@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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: trigger panic on bad page or PTE states if panic_on_oops
  2015-03-16  8:37 [PATCH] mm: trigger panic on bad page or PTE states if panic_on_oops Christian Borntraeger
@ 2015-03-16 11:00 ` Kirill A. Shutemov
  2015-03-16 11:12   ` Christian Borntraeger
  0 siblings, 1 reply; 6+ messages in thread
From: Kirill A. Shutemov @ 2015-03-16 11:00 UTC (permalink / raw)
  To: Christian Borntraeger; +Cc: linux-mm, linux-kernel

On Mon, Mar 16, 2015 at 09:37:01AM +0100, Christian Borntraeger wrote:
> 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.

bed_pte is not an oops.

Probably we should consider putting VM_BUG() at the end of these
functions instead.

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: trigger panic on bad page or PTE states if panic_on_oops
  2015-03-16 11:00 ` Kirill A. Shutemov
@ 2015-03-16 11:12   ` Christian Borntraeger
  2015-03-16 12:15     ` Kirill A. Shutemov
  0 siblings, 1 reply; 6+ messages in thread
From: Christian Borntraeger @ 2015-03-16 11:12 UTC (permalink / raw)
  To: Kirill A. Shutemov; +Cc: linux-mm, linux-kernel

Am 16.03.2015 um 12:00 schrieb Kirill A. Shutemov:
> On Mon, Mar 16, 2015 at 09:37:01AM +0100, Christian Borntraeger wrote:
>> 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.
> 
> bed_pte is not an oops.

I know that this is not an oops, but semantically it is like one.  I certainly
want to a way to hard stop the system if something like that happens.

Would something like panic_on_mm_error be better?

> 
> Probably we should consider putting VM_BUG() at the end of these
> functions instead.

That is probably also a workable solution if I can reproduce the issue on
my system, but VM_BUG  defaults to off for many production systems (RHEL, SLES..)

Any other suggestion?

Christian

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: trigger panic on bad page or PTE states if panic_on_oops
  2015-03-16 11:12   ` Christian Borntraeger
@ 2015-03-16 12:15     ` Kirill A. Shutemov
  2015-03-17 17:19       ` Konstantin Khlebnikov
  0 siblings, 1 reply; 6+ messages in thread
From: Kirill A. Shutemov @ 2015-03-16 12:15 UTC (permalink / raw)
  To: Christian Borntraeger; +Cc: linux-mm, linux-kernel

On Mon, Mar 16, 2015 at 12:12:54PM +0100, Christian Borntraeger wrote:
> Am 16.03.2015 um 12:00 schrieb Kirill A. Shutemov:
> > On Mon, Mar 16, 2015 at 09:37:01AM +0100, Christian Borntraeger wrote:
> >> 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.
> > 
> > bed_pte is not an oops.
> 
> I know that this is not an oops, but semantically it is like one.  I certainly
> want to a way to hard stop the system if something like that happens.
> 
> Would something like panic_on_mm_error be better?

Or panic_on_taint=<mask> where <mask> is bit-mask of TAINT_* values.

The problem is that TAINT_* will effectevely become part of kernel ABI
and I'm not sure it's good idea.

Oopsing on any taint will have limited usefulness, I think.

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: trigger panic on bad page or PTE states if panic_on_oops
  2015-03-16 12:15     ` Kirill A. Shutemov
@ 2015-03-17 17:19       ` Konstantin Khlebnikov
  2015-03-17 19:40         ` Kirill A. Shutemov
  0 siblings, 1 reply; 6+ messages in thread
From: Konstantin Khlebnikov @ 2015-03-17 17:19 UTC (permalink / raw)
  To: Kirill A. Shutemov, Christian Borntraeger; +Cc: linux-mm, linux-kernel

On 16.03.2015 15:15, Kirill A. Shutemov wrote:
> On Mon, Mar 16, 2015 at 12:12:54PM +0100, Christian Borntraeger wrote:
>> Am 16.03.2015 um 12:00 schrieb Kirill A. Shutemov:
>>> On Mon, Mar 16, 2015 at 09:37:01AM +0100, Christian Borntraeger wrote:
>>>> 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.
>>>
>>> bed_pte is not an oops.
>>
>> I know that this is not an oops, but semantically it is like one.  I certainly
>> want to a way to hard stop the system if something like that happens.
>>
>> Would something like panic_on_mm_error be better?
>
> Or panic_on_taint=<mask> where <mask> is bit-mask of TAINT_* values.
>
> The problem is that TAINT_* will effectevely become part of kernel ABI
> and I'm not sure it's good idea.

Taint bits have associated letters: for example panic_on_taint=OP
panic on out-of-tree or propriate =)

>
> Oopsing on any taint will have limited usefulness, I think.
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: trigger panic on bad page or PTE states if panic_on_oops
  2015-03-17 17:19       ` Konstantin Khlebnikov
@ 2015-03-17 19:40         ` Kirill A. Shutemov
  0 siblings, 0 replies; 6+ messages in thread
From: Kirill A. Shutemov @ 2015-03-17 19:40 UTC (permalink / raw)
  To: Konstantin Khlebnikov; +Cc: Christian Borntraeger, linux-mm, linux-kernel

On Tue, Mar 17, 2015 at 08:19:19PM +0300, Konstantin Khlebnikov wrote:
> On 16.03.2015 15:15, Kirill A. Shutemov wrote:
> >On Mon, Mar 16, 2015 at 12:12:54PM +0100, Christian Borntraeger wrote:
> >>Am 16.03.2015 um 12:00 schrieb Kirill A. Shutemov:
> >>>On Mon, Mar 16, 2015 at 09:37:01AM +0100, Christian Borntraeger wrote:
> >>>>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.
> >>>
> >>>bed_pte is not an oops.
> >>
> >>I know that this is not an oops, but semantically it is like one.  I certainly
> >>want to a way to hard stop the system if something like that happens.
> >>
> >>Would something like panic_on_mm_error be better?
> >
> >Or panic_on_taint=<mask> where <mask> is bit-mask of TAINT_* values.
> >
> >The problem is that TAINT_* will effectevely become part of kernel ABI
> >and I'm not sure it's good idea.
> 
> Taint bits have associated letters: for example panic_on_taint=OP
> panic on out-of-tree or propriate =)

Works for me.

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-03-17 19:40 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-16  8:37 [PATCH] mm: trigger panic on bad page or PTE states if panic_on_oops Christian Borntraeger
2015-03-16 11:00 ` Kirill A. Shutemov
2015-03-16 11:12   ` Christian Borntraeger
2015-03-16 12:15     ` Kirill A. Shutemov
2015-03-17 17:19       ` Konstantin Khlebnikov
2015-03-17 19:40         ` Kirill A. Shutemov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).