[PATCH 3/5] stack overflow safe kdump (2.6.16-rc1-i386) - fault

[PATCH 3/5] stack overflow safe kdump (2.6.16-rc1-i386) - fault

[Fernando Luis Vazquez Cao]

When we have a bloated stack it is likely that it ends up making an
invalid memory access that in turn causes a page fault. Take this case
into account in the page fault code.

Signed-off-by: Fernando Vazquez <fernando@intellilink.co.jp>
--- 

diff -urNp linux-2.6.16-rc1/arch/i386/mm/fault.c linux-2.6.16-rc1-sov/arch/i386/mm/fault.c
--- linux-2.6.16-rc1/arch/i386/mm/fault.c	2006-01-03 12:21:10.000000000 +0900
+++ linux-2.6.16-rc1-sov/arch/i386/mm/fault.c	2006-01-25 14:43:13.000000000 +0900
@@ -245,6 +245,11 @@ fastcall void __kprobes do_page_fault(st
 		local_irq_enable();
 
 	tsk = current;
+	/* We may have invalid '*current' due to a stack overflow. */
+	if (!virt_addr_valid(tsk)) {
+		printk("do_page_fault: Discarding invalid 'current' struct task_struct * = 0x%p\n", tsk);
+		tsk = NULL;
+	}
 
 	si_code = SEGV_MAPERR;
 
@@ -271,7 +276,14 @@ fastcall void __kprobes do_page_fault(st
 		goto bad_area_nosemaphore;
 	} 
 
-	mm = tsk->mm;
+	mm = NULL;
+	/* We may have invalid 'tsk' due to a i386 stack overflow */
+	if (tsk)
+		mm = tsk->mm;
+	if (mm && !virt_addr_valid(mm)) {
+		printk("do_page_fault: Discarding invalid current->mm struct mm_struct * = 0x%p\n", mm);
+		mm = NULL;
+	}
 
 	/*
 	 * If we're in an interrupt, have no user context or are running in an

Re: [PATCH 3/5] stack overflow safe kdump (2.6.16-rc1-i386) - fault

[Andrew Morton]

Fernando Luis Vazquez Cao <fernando@intellilink.co.jp> wrote:
>
> When we have a bloated stack it is likely that it ends up making an
> invalid memory access that in turn causes a page fault. Take this case
> into account in the page fault code.
> 
> +	if (!virt_addr_valid(tsk)) {

Is virt_addr_valid() a sufficiently strong test here?  One could probe the
address to see if it generates a fault, like the __get_user() in
kmem_cache_create().


> +		printk("do_page_fault: Discarding invalid 'current' struct task_struct * = 0x%p\n", tsk);
> +		printk("do_page_fault: Discarding invalid current->mm struct mm_struct * = 0x%p\n", mm);

Try to make the code look nice in an 80-col window please.

Re: [PATCH 3/5] stack overflow safe kdump (2.6.16-rc1-i386) - fault

[Andi Kleen]

On Wednesday 25 January 2006 08:15, Andrew Morton wrote:
> Fernando Luis Vazquez Cao <fernando@intellilink.co.jp> wrote:
> > When we have a bloated stack it is likely that it ends up making an
> > invalid memory access that in turn causes a page fault. Take this case
> > into account in the page fault code.
> >
> > +	if (!virt_addr_valid(tsk)) {
>
> Is virt_addr_valid() a sufficiently strong test here?  One could probe the
> address to see if it generates a fault, like the __get_user() in
> kmem_cache_create().

Recursive page faults are always risky because if things go bad they
can lead to unbounded recursion.   I think the scheduler knows anyways
which process currently executes on a CPU so it might be better to get
the information from there.

-Andi

Re: [PATCH 3/5] stack overflow safe kdump (2.6.16-rc1-i386) - fault

[Andrew Morton]

Andi Kleen <ak@suse.de> wrote:
>
> On Wednesday 25 January 2006 08:15, Andrew Morton wrote:
> > Fernando Luis Vazquez Cao <fernando@intellilink.co.jp> wrote:
> > > When we have a bloated stack it is likely that it ends up making an
> > > invalid memory access that in turn causes a page fault. Take this case
> > > into account in the page fault code.
> > >
> > > +	if (!virt_addr_valid(tsk)) {
> >
> > Is virt_addr_valid() a sufficiently strong test here?  One could probe the
> > address to see if it generates a fault, like the __get_user() in
> > kmem_cache_create().
> 
> Recursive page faults are always risky because if things go bad they
> can lead to unbounded recursion.   I think the scheduler knows anyways
> which process currently executes on a CPU so it might be better to get
> the information from there.
> 

It might be nmi-in-interrupt.

But then, the interrupt code knows what CPU it's running on too.