Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Bodo Eggert]

Andi Kleen <ak@suse.de> wrote:

> Matt Mackall <mpm@selenic.com> writes:
> 
>> This adds configurable support for doublefault reporting on x86
> 
> I think that's a bad idea. Users will disable it and then
> send bad bug reports. Better bug reports are worth 4K.

depends on EMBEDDED?
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

[PATCH 6/15] misc: Trim non-IPX builds

[Matt Mackall]

trivial: drop unused 802.3 code if we compile without IPX

(originally from http://wohnheim.fh-wedel.de/~joern/software/kernel/je/25/)

Signed-off-by: Matt Mackall <mpm@selenic.com>

Index: tiny/net/802/Makefile
===================================================================
--- tiny.orig/net/802/Makefile	2005-03-15 00:24:59.000000000 -0600
+++ tiny/net/802/Makefile	2005-03-15 00:25:48.000000000 -0600
@@ -2,8 +2,6 @@
 # Makefile for the Linux 802.x protocol layers.
 #
 
-obj-y			:= p8023.o
-
 # Check the p8022 selections against net/core/Makefile.
 obj-$(CONFIG_SYSCTL)	+= sysctl_net_802.o
 obj-$(CONFIG_LLC)	+= p8022.o psnap.o
@@ -11,5 +9,5 @@ obj-$(CONFIG_TR)	+= p8022.o psnap.o tr.o
 obj-$(CONFIG_NET_FC)	+=                 fc.o
 obj-$(CONFIG_FDDI)	+=                 fddi.o
 obj-$(CONFIG_HIPPI)	+=                 hippi.o
-obj-$(CONFIG_IPX)	+= p8022.o psnap.o
+obj-$(CONFIG_IPX)	+= p8022.o psnap.o p8023.o
 obj-$(CONFIG_ATALK)	+= p8022.o psnap.o

[PATCH 7/15] misc: Make x86 doublefault handling optional

[Matt Mackall]

This adds configurable support for doublefault reporting on x86

add/remove: 0/3 grow/shrink: 0/1 up/down: 0/-13048 (-13048)
function                                     old     new   delta
cpu_init                                     846     786     -60
doublefault_fn                               188       -    -188
doublefault_stack                           4096       -   -4096
doublefault_tss                             8704       -   -8704

Signed-off-by: Matt Mackall <mpm@selenic.com>

Index: 2.6.14-misc/arch/i386/kernel/Makefile
===================================================================
--- 2.6.14-misc.orig/arch/i386/kernel/Makefile	2005-10-27 17:02:08.000000000 -0700
+++ 2.6.14-misc/arch/i386/kernel/Makefile	2005-11-09 11:19:46.000000000 -0800
@@ -7,7 +7,7 @@ extra-y := head.o init_task.o vmlinux.ld
 obj-y	:= process.o semaphore.o signal.o entry.o traps.o irq.o vm86.o \
 		ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_i386.o \
 		pci-dma.o i386_ksyms.o i387.o dmi_scan.o bootflag.o \
-		doublefault.o quirks.o i8237.o
+		quirks.o i8237.o
 
 obj-y				+= cpu/
 obj-y				+= timers/
@@ -33,6 +33,7 @@ obj-y				+= sysenter.o vsyscall.o
 obj-$(CONFIG_ACPI_SRAT) 	+= srat.o
 obj-$(CONFIG_HPET_TIMER) 	+= time_hpet.o
 obj-$(CONFIG_EFI) 		+= efi.o efi_stub.o
+obj-$(CONFIG_DOUBLEFAULT) 	+= doublefault.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 EXTRA_AFLAGS   := -traditional
Index: 2.6.14-misc/arch/i386/kernel/cpu/common.c
===================================================================
--- 2.6.14-misc.orig/arch/i386/kernel/cpu/common.c	2005-11-01 10:54:31.000000000 -0800
+++ 2.6.14-misc/arch/i386/kernel/cpu/common.c	2005-11-09 11:19:46.000000000 -0800
@@ -628,8 +628,10 @@ void __devinit cpu_init(void)
 	load_TR_desc();
 	load_LDT(&init_mm.context);
 
+#ifdef CONFIG_DOUBLEFAULT
 	/* Set up doublefault TSS pointer in the GDT */
 	__set_tss_desc(cpu, GDT_ENTRY_DOUBLEFAULT_TSS, &doublefault_tss);
+#endif
 
 	/* Clear %fs and %gs. */
 	asm volatile ("xorl %eax, %eax; movl %eax, %fs; movl %eax, %gs");
Index: 2.6.14-misc/init/Kconfig
===================================================================
--- 2.6.14-misc.orig/init/Kconfig	2005-11-01 10:54:33.000000000 -0800
+++ 2.6.14-misc/init/Kconfig	2005-11-09 11:19:46.000000000 -0800
@@ -315,6 +315,15 @@ config BUG
           option for embedded systems with no facilities for reporting errors.
           Just say Y.
 
+config DOUBLEFAULT
+	depends X86
+	default y if X86
+	bool "Enable doublefault exception handler" if EMBEDDED
+	help
+          This option allows trapping of rare doublefault exceptions that
+          would otherwise cause a system to silently reboot. Disabling this
+          option saves about 4k.
+
 config BASE_FULL
 	default y
 	bool "Enable full-sized data structures for core" if EMBEDDED

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Andi Kleen]

Matt Mackall <mpm@selenic.com> writes:

> This adds configurable support for doublefault reporting on x86

I think that's a bad idea. Users will disable it and then 
send bad bug reports. Better bug reports are worth 4K.

-Andi

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Rob Landley]

On Friday 11 November 2005 02:35, Matt Mackall wrote:
> This adds configurable support for doublefault reporting on x86
...
> +config DOUBLEFAULT
> + depends X86
> + default y if X86
> + bool "Enable doublefault exception handler" if EMBEDDED
> + help
> +          This option allows trapping of rare doublefault exceptions that
> +          would otherwise cause a system to silently reboot. Disabling
> this +          option saves about 4k.
> +

What causes doublefaults?  Is it triggerable from userspace, or is it 
something funky the kernel does?

Trying to figure out when it would be worth using this...

Rob

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Matt Mackall]

On Wed, Nov 16, 2005 at 07:13:07AM -0600, Rob Landley wrote:
> On Friday 11 November 2005 02:35, Matt Mackall wrote:
> > This adds configurable support for doublefault reporting on x86
> ...
> > +config DOUBLEFAULT
> > + depends X86
> > + default y if X86
> > + bool "Enable doublefault exception handler" if EMBEDDED
> > + help
> > +          This option allows trapping of rare doublefault exceptions that
> > +          would otherwise cause a system to silently reboot. Disabling
> > this +          option saves about 4k.
> > +
> 
> What causes doublefaults?  Is it triggerable from userspace, or is it 
> something funky the kernel does?

Double faults happen when a fault occurs while entering a fault
handler.

They're extremely rare in the field. In my experience, they only occur
when you've got hardware troubles or are hacking on the fault handling
code. They're rare enough that I showed one to akpm a few months back
and he claimed he'd never seen one before.

If a fault occurs while trying to invoke the double fault handler
(perhaps because you don't have one), you get a triple fault which
causes a reboot. 

> Trying to figure out when it would be worth using this...

Typical usage for this and similar options is in boxes that have no
useful logging or diagnostic facilities.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Scott Garfinkle]

I tend to agree with the spirit of Andi's comment -- disabling this
will (I think) make the rare time when it happens into something
impossible to debug without a new kernel and reproducing the problem.
Not being familiar with EMBEDDED, I am curious whether the savings is
critical.

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Adrian Bunk]

On Wed, Nov 16, 2005 at 01:21:48PM -0600, Scott Garfinkle wrote:

> I tend to agree with the spirit of Andi's comment -- disabling this
> will (I think) make the rare time when it happens into something
> impossible to debug without a new kernel and reproducing the problem.
> Not being familiar with EMBEDDED, I am curious whether the savings is
> critical.

menuconfig EMBEDDED
        bool "Configure standard kernel features (for small systems)"
        help
          This option allows certain base kernel options and settings
          to be disabled or tweaked. This is for specialized
          environments which can tolerate a "non-standard" kernel.
          Only use this if you really know what you are doing.

So yes, Matt's patch does make sense.

cu
Adrian

BTW: Don't strip the Cc when replying to linux-kernel.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Ingo Molnar]

* Scott Garfinkle <scotteglist@gmail.com> wrote:

> I tend to agree with the spirit of Andi's comment -- disabling this 
> will (I think) make the rare time when it happens into something 
> impossible to debug without a new kernel and reproducing the problem.

in the past couple of years i saw double-faults at a rate of perhaps 
once a year - and i frequently hack lowlevel glue code! So the 
usefulness of this code in the field, and especially on an embedded 
platforms, is extremely limited.

in fact, i've experienced triple-faults (== spontaneous reboots) to be 
at least 10 times more frequent than double-faults! I.e. _if_ your 
kernel (or hardware) is screwed up to the degree that it would 
double-fault, it will much more likely also triple-fault.

IIRC we added the double-fault handler to debug the PAE code originally.  
Now years down the road, making it configurable-out if EMBEDDED makes 
lots of sense.

	Ingo

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Andi Kleen]

Ingo Molnar <mingo@elte.hu> writes:
> 
> in the past couple of years i saw double-faults at a rate of perhaps 
> once a year - and i frequently hack lowlevel glue code! So the 
> usefulness of this code in the field, and especially on an embedded 
> platforms, is extremely limited.

If it only saves an hour or developer time on some bug report
it has already justified its value.

Also to really save memory there are much better areas
of attack than this relatively slim code.

> in fact, i've experienced triple-faults (== spontaneous reboots) to be 
> at least 10 times more frequent than double-faults! I.e. _if_ your 
> kernel (or hardware) is screwed up to the degree that it would 
> double-fault, it will much more likely also triple-fault.

A common case where this doesn't hold is breaking the [er]sp 
in kernel code.

-Andi (who sees double faults more often) 

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Matt Mackall]

On Mon, Dec 12, 2005 at 09:22:42AM -0700, Andi Kleen wrote:
> Ingo Molnar <mingo@elte.hu> writes:
> > 
> > in the past couple of years i saw double-faults at a rate of perhaps 
> > once a year - and i frequently hack lowlevel glue code! So the 
> > usefulness of this code in the field, and especially on an embedded 
> > platforms, is extremely limited.
> 
> If it only saves an hour or developer time on some bug report
> it has already justified its value.
> 
> Also to really save memory there are much better areas
> of attack than this relatively slim code.

Such as? Odds are good I've already attacked them, but I'd be happy
for some new ideas.

I think anything easily disabled larger than 1k is a pretty decent
target in a minimal config.

> -Andi (who sees double faults more often) 

You will *not* see them on a platform with no console and no printk,
hence CONFIG_EMBEDDED. Can we be done with this yet?

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH 7/15] misc: Make x86 doublefault handling optional

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> Ingo Molnar <mingo@elte.hu> writes:
> > 
> > in the past couple of years i saw double-faults at a rate of perhaps 
> > once a year - and i frequently hack lowlevel glue code! So the 
> > usefulness of this code in the field, and especially on an embedded 
> > platforms, is extremely limited.
> 
> If it only saves an hour or developer time on some bug report it has 
> already justified its value.

yes, of course. Are you arguing that all debugging options should be 
made unconditional? Matt's patch simply makes double-fault-debugging 
optional. More than that, it will still be unconditionally enabled 
unless CONFIG_EMBEDDED is specified.

> Also to really save memory there are much better areas of attack than 
> this relatively slim code.

the dynamics of memory reduction patches is just like the dynamics of 
scalability patches: we have to attack on _every front_ and even then 
progress will appear to be very slow. We almost never reject a 
scalability micro-optimization just because there might be larger fruits 
hanging.

> > in fact, i've experienced triple-faults (== spontaneous reboots) to 
> > be at least 10 times more frequent than double-faults! I.e. _if_ 
> > your kernel (or hardware) is screwed up to the degree that it would 
> > double-fault, it will much more likely also triple-fault.
> 
> A common case where this doesn't hold is breaking the [er]sp in kernel 
> code.
> 
> -Andi (who sees double faults more often)

yeah. Still, i see no problem with making it optional. (as long as it 
does not result in significant uglification of the code - which clearly 
is not a problem for this particular patch.)

	Ingo