public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] (3/3) stack overflow checking for x86
@ 2002-10-18 22:07 Dave Hansen
  2002-10-18 22:31 ` Dave Hansen
  0 siblings, 1 reply; 8+ messages in thread
From: Dave Hansen @ 2002-10-18 22:07 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel

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

* stack checking (3/3)
    - use gcc's profiling features to check for stack overflows upon
      entry to functions.
    - Warn if the task goes over 4k.
    - Panic if the stack gets within 512 bytes of overflowing.
    - use kksymoops information, if available

This won't apply cleanly without the irqstack patch, but the conflict 
is easy to resolve.  It requires the thread_info cleanup.
-- 
Dave Hansen
haveblue@us.ibm.com

[-- Attachment #2: C-stack_usage_check-2.5.43+bk-1.patch --]
[-- Type: text/plain, Size: 7667 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.858.1.2 -> 1.863  
#	arch/i386/kernel/process.c	1.32.1.1 -> 1.36   
#	arch/i386/Config.help	1.21.1.2 -> 1.24   
#	            Makefile	1.320.1.1 -> 1.322  
#	include/asm-i386/thread_info.h	1.10    -> 1.11   
#	arch/i386/kernel/entry.S	1.38.1.2 -> 1.45   
#	 arch/i386/config.in	1.56.1.4 -> 1.59   
#	  arch/i386/Makefile	1.21.1.1 -> 1.23   
#	arch/i386/boot/compressed/misc.c	1.9     -> 1.10   
#	arch/i386/kernel/init_task.c	1.6.1.1 -> 1.8    
#	arch/i386/kernel/i386_ksyms.c	1.34.1.2 -> 1.36   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/10/16	haveblue@elm3b96.(none)	1.861
# change warning semantics
# --------------------------------------------
# 02/10/16	haveblue@elm3b96.(none)	1.862
# entry.S:
#   don't need stack_warn_lock anymore
# --------------------------------------------
# 02/10/16	haveblue@elm3b96.(none)	1.863
# merge
# --------------------------------------------
#
diff -Nru a/Makefile b/Makefile
--- a/Makefile	Wed Oct 16 14:14:00 2002
+++ b/Makefile	Wed Oct 16 14:14:00 2002
@@ -156,7 +156,8 @@
 
 CPPFLAGS	:= -D__KERNEL__ -Iinclude
 CFLAGS 		:= $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
-	  	   -fomit-frame-pointer -fno-strict-aliasing -fno-common
+	  	   -fno-strict-aliasing -fno-common
+
 AFLAGS		:= -D__ASSEMBLY__ $(CPPFLAGS)
 
 export	VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
@@ -255,6 +256,10 @@
 
 ifdef CONFIG_MODULES
 export EXPORT_FLAGS := -DEXPORT_SYMTAB
+endif
+
+ifneq ($(CONFIG_FRAME_POINTER),y)
+CFLAGS          += -fomit-frame-pointer
 endif
 
 #
diff -Nru a/arch/i386/Config.help b/arch/i386/Config.help
--- a/arch/i386/Config.help	Wed Oct 16 14:14:00 2002
+++ b/arch/i386/Config.help	Wed Oct 16 14:14:00 2002
@@ -1050,6 +1050,20 @@
   symbolic stack backtraces. This increases the size of the kernel
   somewhat, as all symbols have to be loaded into the kernel image.
 
+CONFIG_X86_STACK_CHECK
+  Say Y here to have the kernel attempt to detect when the per-task
+  kernel stack overflows. 
+
+  Some older versions of gcc don't handle the -p option correctly.  
+  Kernprof is affected by the same problem, which is described here:
+  http://oss.sgi.com/projects/kernprof/faq.html#Q9
+
+  Basically, if you get oopses in __free_pages_ok during boot when
+  you have this turned on, you need to fix gcc.  The Redhat 2.96 
+  version and gcc-3.x seem to work.  
+
+  If not debugging a stack overflow problem, say N
+
 CONFIG_DEBUG_OBSOLETE
   Say Y here if you want to reduce the chances of the tree compiling,
   and are prepared to dig into driver internals to fix compile errors.
diff -Nru a/arch/i386/Makefile b/arch/i386/Makefile
--- a/arch/i386/Makefile	Wed Oct 16 14:14:00 2002
+++ b/arch/i386/Makefile	Wed Oct 16 14:14:00 2002
@@ -49,6 +49,10 @@
 MACHINE	:= mach-generic
 endif
 
+ifdef CONFIG_X86_STACK_CHECK
+CFLAGS += -p
+endif
+
 HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
 
 libs-y 					+= arch/i386/lib/
diff -Nru a/arch/i386/boot/compressed/misc.c b/arch/i386/boot/compressed/misc.c
--- a/arch/i386/boot/compressed/misc.c	Wed Oct 16 14:14:00 2002
+++ b/arch/i386/boot/compressed/misc.c	Wed Oct 16 14:14:00 2002
@@ -377,3 +377,7 @@
 	if (high_loaded) close_output_buffer_if_we_run_high(mv);
 	return high_loaded;
 }
+
+/* We don't actually check for stack overflows this early. */
+__asm__(".globl mcount ; mcount: ret\n");
+
diff -Nru a/arch/i386/config.in b/arch/i386/config.in
--- a/arch/i386/config.in	Wed Oct 16 14:14:00 2002
+++ b/arch/i386/config.in	Wed Oct 16 14:14:00 2002
@@ -467,6 +467,11 @@
       bool '  Highmem debugging' CONFIG_DEBUG_HIGHMEM
    fi
    bool '  Load all symbols for debugging/kksymoops' CONFIG_KALLSYMS
+   bool '  Check for stack overflows' CONFIG_X86_STACK_CHECK
+   if [ "$CONFIG_X86_STACK_CHECK" = "y" ]; then
+      define_bool CONFIG_FRAME_POINTER y
+   fi
+
 fi
 
 if [ "$CONFIG_X86_LOCAL_APIC" = "y" ]; then
diff -Nru a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S	Wed Oct 16 14:14:00 2002
+++ b/arch/i386/kernel/entry.S	Wed Oct 16 14:14:00 2002
@@ -519,6 +519,61 @@
 	pushl $do_spurious_interrupt_bug
 	jmp error_code
 
+
+#ifdef CONFIG_X86_STACK_CHECK
+.data
+	.globl	stack_overflowed
+stack_overflowed:
+	.long	0
+.text
+
+ENTRY(mcount)
+	push %eax
+	movl $(THREAD_SIZE - 1),%eax
+	andl %esp,%eax
+	cmpl $STACK_WARN,%eax	/* more than half the stack is used*/
+	jle 1f
+2:
+	popl %eax
+	ret
+1:	
+	lock;   btsl    $0,stack_overflowed
+	jc      2b
+	
+	# switch to overflow stack
+	movl	%esp,%eax
+	movl	$(stack_overflow_stack + THREAD_SIZE - 4),%esp
+
+	pushf
+	cli
+	pushl	%eax
+
+	# push eip then esp of error for stack_overflow_panic
+	pushl	4(%eax)
+	pushl	%eax
+
+	# update the task pointer and cpu in the overflow stack's thread_info.
+	GET_THREAD_INFO_WITH_ESP(%eax)
+	movl	TI_TASK(%eax),%ebx
+	movl	%ebx,stack_overflow_stack+TI_TASK
+	movl	TI_CPU(%eax),%ebx
+	movl	%ebx,stack_overflow_stack+TI_CPU
+
+	call	stack_overflow
+
+	# pop off call arguments
+	addl	$8,%esp 
+
+	popl	%eax
+	popf
+	movl	%eax,%esp
+	popl	%eax
+	movl	$0,stack_overflowed
+	ret
+
+#warning stack check enabled
+#endif
+
 .data
 ENTRY(sys_call_table)
 	.long sys_ni_syscall	/* 0 - old "setup()" system call*/
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c	Wed Oct 16 14:14:00 2002
+++ b/arch/i386/kernel/i386_ksyms.c	Wed Oct 16 14:14:00 2002
@@ -192,3 +192,8 @@
 EXPORT_SYMBOL(is_sony_vaio_laptop);
 
 EXPORT_SYMBOL(__PAGE_KERNEL);
+
+#ifdef CONFIG_X86_STACK_CHECK
+extern void mcount(void);
+EXPORT_SYMBOL(mcount);
+#endif
diff -Nru a/arch/i386/kernel/init_task.c b/arch/i386/kernel/init_task.c
--- a/arch/i386/kernel/init_task.c	Wed Oct 16 14:14:00 2002
+++ b/arch/i386/kernel/init_task.c	Wed Oct 16 14:14:00 2002
@@ -16,6 +16,10 @@
 union thread_union init_irq_union
 	__attribute__((__section__(".data.init_task")));
 
+#ifdef CONFIG_X86_STACK_CHECK
+union thread_union stack_overflow_stack
+	__attribute__((__section__(".data.init_task")));
+#endif
 
 /*
  * Initial thread structure.
diff -Nru a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c	Wed Oct 16 14:14:00 2002
+++ b/arch/i386/kernel/process.c	Wed Oct 16 14:14:00 2002
@@ -156,7 +156,25 @@
 
 __setup("idle=", idle_setup);
 
-void show_regs(struct pt_regs * regs)
+void stack_overflow(unsigned long esp, unsigned long eip)
+{
+	int panicing = ((esp&(THREAD_SIZE-1)) <= STACK_PANIC);
+
+	printk( "esp: 0x%x masked: 0x%x STACK_PANIC:0x%x %d %d\n", 
+		esp, (esp&(THREAD_SIZE-1)), STACK_PANIC, (((esp&(THREAD_SIZE-1)) <= STACK_PANIC)), panicing );
+	
+	if (panicing)
+		print_symbol("stack overflow from %s\n", eip);
+	else
+		print_symbol("excessive stack use from %s\n", eip);
+	printk("esp: %p\n", (void*)esp);
+	show_trace((void*)esp);
+	
+	if (panicing)
+		panic("stack overflow\n");
+}
+
+asmlinkage void show_regs(struct pt_regs * regs)
 {
 	unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
 
diff -Nru a/include/asm-i386/thread_info.h b/include/asm-i386/thread_info.h
--- a/include/asm-i386/thread_info.h	Wed Oct 16 14:14:00 2002
+++ b/include/asm-i386/thread_info.h	Wed Oct 16 14:14:00 2002
@@ -60,6 +60,8 @@
  */
 #define THREAD_ORDER 1 
 #define INIT_THREAD_SIZE       THREAD_SIZE
+#define STACK_PANIC		0x200ul
+#define STACK_WARN		((THREAD_SIZE)>>1)
 
 #ifndef __ASSEMBLY__
 #define INIT_THREAD_INFO(tsk)			\

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

* Re: [PATCH] (3/3) stack overflow checking for x86
  2002-10-18 22:07 [PATCH] (3/3) stack overflow checking for x86 Dave Hansen
@ 2002-10-18 22:31 ` Dave Hansen
  2002-10-18 22:48   ` Andreas Dilger
  0 siblings, 1 reply; 8+ messages in thread
From: Dave Hansen @ 2002-10-18 22:31 UTC (permalink / raw)
  To: Dave Hansen; +Cc: Linus Torvalds, linux-kernel

Dave Hansen wrote:
> * stack checking (3/3)
>    - use gcc's profiling features to check for stack overflows upon
>      entry to functions.
>    - Warn if the task goes over 4k.
>    - Panic if the stack gets within 512 bytes of overflowing.
>    - use kksymoops information, if available
> 
> This won't apply cleanly without the irqstack patch, but the conflict is 
> easy to resolve.  It requires the thread_info cleanup.

Greg KH just pointed out that someone else snuck in an overflow check. 
  However, they take completely different approaches.  The Ben LaHaise 
one that I posted uses GCC features to check the stack on entry to all 
functions.  The one in the tree now is much, much simpler than Ben's, 
but only works only for detecting problems at the time that an 
interrupt actually occurs.

-- 
Dave Hansen
haveblue@us.ibm.com


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

* Re: [PATCH] (3/3) stack overflow checking for x86
  2002-10-18 22:31 ` Dave Hansen
@ 2002-10-18 22:48   ` Andreas Dilger
  0 siblings, 0 replies; 8+ messages in thread
From: Andreas Dilger @ 2002-10-18 22:48 UTC (permalink / raw)
  To: Dave Hansen; +Cc: Linus Torvalds, linux-kernel

On Oct 18, 2002  15:31 -0700, Dave Hansen wrote:
> Greg KH just pointed out that someone else snuck in an overflow check. 
>  However, they take completely different approaches.  The Ben LaHaise 
> one that I posted uses GCC features to check the stack on entry to all 
> functions.  The one in the tree now is much, much simpler than Ben's, 
> but only works only for detecting problems at the time that an 
> interrupt actually occurs.

Yes, we had that patch in the RH 2.4 kernel, but it didn't detect the
stack overflow we spent days to track.  Our problem was just one of
a really deep stack: RPC-to-network-filesystem-on-ext3-with-htree.
This overflowed the 8kB stack even without an interrupt happening.

We fixed the htree and the network filesystem stack usage, but if we
added LVM/EVMS into the mix (which we would have in production) and
threw in a piggy interrupt handler we would possibly again overflow
an 8kB stack, so having a per-entry/exit stack checker would be great.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/


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

* [PATCH] (3/3) stack overflow checking for x86
  2002-10-31 19:18 [PATCH] (1/3) cleanup thread info on x86 David C. Hansen
@ 2002-10-31 19:20 ` David C. Hansen
  2002-10-31 21:30   ` Dave Jones
  0 siblings, 1 reply; 8+ messages in thread
From: David C. Hansen @ 2002-10-31 19:20 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: lkml

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

* stack checking (3/3)
   - use gcc's profiling features to check for stack overflows upon
     entry to functions.
   - Warn if the task goes over 4k.
   - Panic if the stack gets within 512 bytes of overflowing.
   - use kksymoops information, if available

This won't apply cleanly without the irqstack patch, but the conflict is
easy to resolve.  It requires the thread_info cleanup.
-- 
Dave Hansen
haveblue@us.ibm.com

[-- Attachment #2: C-stack_usage_check-2.5.45-4.patch --]
[-- Type: text/plain, Size: 6119 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.857.1.1 -> 1.859  
#	arch/i386/kernel/process.c	1.32.1.1 -> 1.36   
#	arch/i386/kernel/irq.c	1.23.1.1 -> 1.25   
#	            Makefile	1.326.2.11 -> 1.329  
#	include/asm-i386/thread_info.h	1.10    -> 1.11   
#	arch/i386/kernel/entry.S	1.38.1.3 -> 1.46   
#	  arch/i386/Makefile	1.24.2.3 -> 1.27   
#	arch/i386/boot/compressed/misc.c	1.9     -> 1.10   
#	arch/i386/kernel/init_task.c	1.6.1.1 -> 1.8    
#	arch/i386/kernel/i386_ksyms.c	1.36.2.3 -> 1.39   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/10/31	haveblue@elm3b96.(none)	1.859
# Merge elm3b96.(none):/work/dave/bk/linux-2.5-irq-stack
# into elm3b96.(none):/work/dave/bk/linux-2.5-irq-stack+overflow-detect
# --------------------------------------------
#
diff -Nru a/Makefile b/Makefile
--- a/Makefile	Thu Oct 31 11:13:28 2002
+++ b/Makefile	Thu Oct 31 11:13:28 2002
@@ -168,7 +168,8 @@
 
 CPPFLAGS	:= -D__KERNEL__ -Iinclude
 CFLAGS 		:= $(CPPFLAGS) -Wall -Wstrict-prototypes -Wno-trigraphs -O2 \
-	  	   -fomit-frame-pointer -fno-strict-aliasing -fno-common
+	  	   -fno-strict-aliasing -fno-common
+
 AFLAGS		:= -D__ASSEMBLY__ $(CPPFLAGS)
 
 export	VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION KERNELRELEASE ARCH \
@@ -254,6 +255,10 @@
 
 ifdef CONFIG_MODULES
 export EXPORT_FLAGS := -DEXPORT_SYMTAB
+endif
+
+ifneq ($(CONFIG_FRAME_POINTER),y)
+CFLAGS          += -fomit-frame-pointer
 endif
 
 #
diff -Nru a/arch/i386/Makefile b/arch/i386/Makefile
--- a/arch/i386/Makefile	Thu Oct 31 11:13:28 2002
+++ b/arch/i386/Makefile	Thu Oct 31 11:13:28 2002
@@ -51,6 +51,10 @@
 MACHINE	:= mach-generic
 endif
 
+ifdef CONFIG_X86_STACK_CHECK
+CFLAGS += -p
+endif
+
 HEAD := arch/i386/kernel/head.o arch/i386/kernel/init_task.o
 
 libs-y 					+= arch/i386/lib/
diff -Nru a/arch/i386/boot/compressed/misc.c b/arch/i386/boot/compressed/misc.c
--- a/arch/i386/boot/compressed/misc.c	Thu Oct 31 11:13:28 2002
+++ b/arch/i386/boot/compressed/misc.c	Thu Oct 31 11:13:28 2002
@@ -377,3 +377,7 @@
 	if (high_loaded) close_output_buffer_if_we_run_high(mv);
 	return high_loaded;
 }
+
+/* We don't actually check for stack overflows this early. */
+__asm__(".globl mcount ; mcount: ret\n");
+
diff -Nru a/arch/i386/kernel/entry.S b/arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S	Thu Oct 31 11:13:28 2002
+++ b/arch/i386/kernel/entry.S	Thu Oct 31 11:13:28 2002
@@ -519,6 +519,61 @@
 	pushl $do_spurious_interrupt_bug
 	jmp error_code
 
+
+#ifdef CONFIG_X86_STACK_CHECK
+.data
+	.globl	stack_overflowed
+stack_overflowed:
+	.long	0
+.text
+
+ENTRY(mcount)
+	push %eax
+	movl $(THREAD_SIZE - 1),%eax
+	andl %esp,%eax
+	cmpl $STACK_WARN,%eax	/* more than half the stack is used*/
+	jle 1f
+2:
+	popl %eax
+	ret
+1:	
+	lock;   btsl    $0,stack_overflowed
+	jc      2b
+	
+	# switch to overflow stack
+	movl	%esp,%eax
+	movl	$(stack_overflow_stack + THREAD_SIZE - 4),%esp
+
+	pushf
+	cli
+	pushl	%eax
+
+	# push eip then esp of error for stack_overflow_panic
+	pushl	4(%eax)
+	pushl	%eax
+
+	# update the task pointer and cpu in the overflow stack's thread_info.
+	GET_THREAD_INFO_WITH_ESP(%eax)
+	movl	TI_TASK(%eax),%ebx
+	movl	%ebx,stack_overflow_stack+TI_TASK
+	movl	TI_CPU(%eax),%ebx
+	movl	%ebx,stack_overflow_stack+TI_CPU
+
+	call	stack_overflow
+
+	# pop off call arguments
+	addl	$8,%esp 
+
+	popl	%eax
+	popf
+	movl	%eax,%esp
+	popl	%eax
+	movl	$0,stack_overflowed
+	ret
+
+#warning stack check enabled
+#endif
+
 .data
 ENTRY(sys_call_table)
 	.long sys_ni_syscall	/* 0 - old "setup()" system call*/
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c	Thu Oct 31 11:13:28 2002
+++ b/arch/i386/kernel/i386_ksyms.c	Thu Oct 31 11:13:28 2002
@@ -211,3 +211,8 @@
 EXPORT_SYMBOL(edd);
 EXPORT_SYMBOL(eddnr);
 #endif
+
+#ifdef CONFIG_X86_STACK_CHECK
+extern void mcount(void);
+EXPORT_SYMBOL(mcount);
+#endif
diff -Nru a/arch/i386/kernel/init_task.c b/arch/i386/kernel/init_task.c
--- a/arch/i386/kernel/init_task.c	Thu Oct 31 11:13:28 2002
+++ b/arch/i386/kernel/init_task.c	Thu Oct 31 11:13:28 2002
@@ -16,6 +16,10 @@
 union thread_union init_irq_union
 	__attribute__((__section__(".data.init_task")));
 
+#ifdef CONFIG_X86_STACK_CHECK
+union thread_union stack_overflow_stack
+	__attribute__((__section__(".data.init_task")));
+#endif
 
 /*
  * Initial thread structure.
diff -Nru a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c	Thu Oct 31 11:13:28 2002
+++ b/arch/i386/kernel/process.c	Thu Oct 31 11:13:28 2002
@@ -156,7 +156,25 @@
 
 __setup("idle=", idle_setup);
 
-void show_regs(struct pt_regs * regs)
+void stack_overflow(unsigned long esp, unsigned long eip)
+{
+	int panicing = ((esp&(THREAD_SIZE-1)) <= STACK_PANIC);
+
+	printk( "esp: 0x%x masked: 0x%x STACK_PANIC:0x%x %d %d\n", 
+		esp, (esp&(THREAD_SIZE-1)), STACK_PANIC, (((esp&(THREAD_SIZE-1)) <= STACK_PANIC)), panicing );
+	
+	if (panicing)
+		print_symbol("stack overflow from %s\n", eip);
+	else
+		print_symbol("excessive stack use from %s\n", eip);
+	printk("esp: %p\n", (void*)esp);
+	show_trace((void*)esp);
+	
+	if (panicing)
+		panic("stack overflow\n");
+}
+
+asmlinkage void show_regs(struct pt_regs * regs)
 {
 	unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
 
diff -Nru a/include/asm-i386/thread_info.h b/include/asm-i386/thread_info.h
--- a/include/asm-i386/thread_info.h	Thu Oct 31 11:13:28 2002
+++ b/include/asm-i386/thread_info.h	Thu Oct 31 11:13:28 2002
@@ -60,6 +60,8 @@
  */
 #define THREAD_ORDER 1 
 #define INIT_THREAD_SIZE       THREAD_SIZE
+#define STACK_PANIC		0x200ul
+#define STACK_WARN		((THREAD_SIZE)>>1)
 
 #ifndef __ASSEMBLY__
 #define INIT_THREAD_INFO(tsk)			\

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

* Re: [PATCH] (3/3) stack overflow checking for x86
  2002-10-31 19:20 ` [PATCH] (3/3) stack overflow checking for x86 David C. Hansen
@ 2002-10-31 21:30   ` Dave Jones
  2002-10-31 22:08     ` David C. Hansen
  2002-11-01 12:59     ` Alan Cox
  0 siblings, 2 replies; 8+ messages in thread
From: Dave Jones @ 2002-10-31 21:30 UTC (permalink / raw)
  To: David C. Hansen; +Cc: Linus Torvalds, lkml

On Thu, Oct 31, 2002 at 11:20:52AM -0800, David C. Hansen wrote:
 > * stack checking (3/3)
 >    - use gcc's profiling features to check for stack overflows upon
 >      entry to functions.
 >    - Warn if the task goes over 4k.
 >    - Panic if the stack gets within 512 bytes of overflowing.
 >    - use kksymoops information, if available
 > 
 > This won't apply cleanly without the irqstack patch, but the conflict is
 > easy to resolve.  It requires the thread_info cleanup.

I'm wondering about interaction between this patch and the
already merged CONFIG_DEBUG_STACKOVERFLOW ?

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

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

* Re: [PATCH] (3/3) stack overflow checking for x86
  2002-10-31 21:30   ` Dave Jones
@ 2002-10-31 22:08     ` David C. Hansen
  2002-11-01 12:59     ` Alan Cox
  1 sibling, 0 replies; 8+ messages in thread
From: David C. Hansen @ 2002-10-31 22:08 UTC (permalink / raw)
  To: Dave Jones; +Cc: Linus Torvalds, lkml

On Thu, 2002-10-31 at 13:30, Dave Jones wrote:
> On Thu, Oct 31, 2002 at 11:20:52AM -0800, David C. Hansen wrote:
>  > * stack checking (3/3)
>  >    - use gcc's profiling features to check for stack overflows upon
>  >      entry to functions.
>  >    - Warn if the task goes over 4k.
>  >    - Panic if the stack gets within 512 bytes of overflowing.
>  >    - use kksymoops information, if available
>  > 
>  > This won't apply cleanly without the irqstack patch, but the conflict is
>  > easy to resolve.  It requires the thread_info cleanup.
> 
> I'm wondering about interaction between this patch and the
> already merged CONFIG_DEBUG_STACKOVERFLOW ?

The currently merged one is very, very simple, but relatively worthless.
There are no guarantees about catching an overflow, especially if it
happens in a long call chain _after_ do_IRQ with interrupts disabled.  
Ben's version checks on entrance to every function, making it _much_
more likely to be caught, even during an interrupt.  But, the currently
merged one doesn't have any strange compiler requirements, like adding
the -p option.

The irq stack patch would make the current check pretty worthless
because the check happens just after the switch to a fresh irqstack
would have happened.

But, if they both get in, it can be cleaned up later because even if
both are turned on, nothing will blow up.  
-- 
Dave Hansen
haveblue@us.ibm.com


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

* Re: [PATCH] (3/3) stack overflow checking for x86
  2002-10-31 21:30   ` Dave Jones
  2002-10-31 22:08     ` David C. Hansen
@ 2002-11-01 12:59     ` Alan Cox
  2002-11-01 13:42       ` Dave Jones
  1 sibling, 1 reply; 8+ messages in thread
From: Alan Cox @ 2002-11-01 12:59 UTC (permalink / raw)
  To: Dave Jones; +Cc: David C. Hansen, Linus Torvalds, lkml

On Thu, 2002-10-31 at 21:30, Dave Jones wrote:
>  > This won't apply cleanly without the irqstack patch, but the conflict is
>  > easy to resolve.  It requires the thread_info cleanup.
> 
> I'm wondering about interaction between this patch and the
> already merged CONFIG_DEBUG_STACKOVERFLOW ?

It replaces it and actually makes it useful since IRQ usage is now
bounded and defined relative to non IRQ usage. Without IRQ stacks you
don't have a hope in hell of catching overflows that depend on an irq
occuring at the right moment


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

* Re: [PATCH] (3/3) stack overflow checking for x86
  2002-11-01 12:59     ` Alan Cox
@ 2002-11-01 13:42       ` Dave Jones
  0 siblings, 0 replies; 8+ messages in thread
From: Dave Jones @ 2002-11-01 13:42 UTC (permalink / raw)
  To: Alan Cox; +Cc: David C. Hansen, Linus Torvalds, lkml

On Fri, Nov 01, 2002 at 12:59:06PM +0000, Alan Cox wrote:
 > On Thu, 2002-10-31 at 21:30, Dave Jones wrote:
 > >  > This won't apply cleanly without the irqstack patch, but the conflict is
 > >  > easy to resolve.  It requires the thread_info cleanup.
 > > 
 > > I'm wondering about interaction between this patch and the
 > > already merged CONFIG_DEBUG_STACKOVERFLOW ?
 > 
 > It replaces it and actually makes it useful since IRQ usage is now
 > bounded and defined relative to non IRQ usage. Without IRQ stacks you
 > don't have a hope in hell of catching overflows that depend on an irq
 > occuring at the right moment

 Yeah, I figured it worked better, but wondered why the patch didn't
 remove the existing implementation.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

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

end of thread, other threads:[~2002-11-01 13:37 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-18 22:07 [PATCH] (3/3) stack overflow checking for x86 Dave Hansen
2002-10-18 22:31 ` Dave Hansen
2002-10-18 22:48   ` Andreas Dilger
  -- strict thread matches above, loose matches on Subject: below --
2002-10-31 19:18 [PATCH] (1/3) cleanup thread info on x86 David C. Hansen
2002-10-31 19:20 ` [PATCH] (3/3) stack overflow checking for x86 David C. Hansen
2002-10-31 21:30   ` Dave Jones
2002-10-31 22:08     ` David C. Hansen
2002-11-01 12:59     ` Alan Cox
2002-11-01 13:42       ` Dave Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox