profile_pc oops in 2.6.18

[Dave Grothe <dave@gcom.com>]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

I have had a problem with a kernel oops in 2.6.18 with the kernel
compiled with stack frame pointers and a loadable module compiled
without stack frame pointers.

I have a patch that fixes the problem for 2.6.18.  It is attached to 
this email.

-- Dave  

[-- Attachment #2: patch-time.c --]
[-- Type: application/octet-stream, Size: 1316 bytes --]

This patch fixes a problem involving a kernel crash.

If the kernel is compiled with frame pointers and a module that was
compiled without frame pointers is loaded and run; and if the 
kernel profile_pc routine gets called while that module is in a
spin lock, then regs->ebp does not contain a valid frame pointer
and the access to *(regs->ebp+4) produces (usually) an access to
an invalid address.

This patch implements a check to see that the regs->ebp value lies
within the thread_info region for the current process.

The patch is for 2.6.18, as I am testing on CentOS-5.  However,
looking at 2.6.25 it seems that it would easily apply to that
kernel version as well, with just a little manual fitting.

Dave Grothe 29Apr2008

--- arch/i386/kernel/time.c.orig	2008-04-29 11:02:02.000000000 -0500
+++ arch/i386/kernel/time.c	2008-04-29 13:28:35.000000000 -0500
@@ -136,7 +136,14 @@
 	unsigned long pc = instruction_pointer(regs);
 
 	if (!user_mode_vm(regs) && in_lock_functions(pc))
-		return *(unsigned long *)(regs->ebp + 4);
+	{			/* is bp a valid stack address?   */
+	    uint32_t ti_base = (uint32_t)current_thread_info() ;
+
+	    if (regs->ebp >= ti_base && regs->ebp < ti_base + THREAD_SIZE)
+		return *(unsigned long *)(regs->ebp + 4);	/* yes, use it*/
+	    else
+		return pc ;
+	}
 
 	return pc;
 }

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]