Unknown traps.

Unknown traps.

[Martin Schwidefsky]

Hi,
while working on a deficiency in the illegal operation handler for
s390 (only emits a force_sig instead of a force_sig_info) I stumbled
over something odd: How are unknown traps handled properly?

Of the architectures where I have some clue what they are doing:

i386: doesn't handle unknown traps (idt_table entries with {0,0})
ia64: does a force_sig with SIGILL.
parisc: does a force_sig_info with SIGBUS/BUS_OBJERR.
ppc: doesn't handle unknown traps (?).
s390: does a force_sig with SIGSEGV.
sparc: does a force_sig_info with SIGILL/ILL_ILLTRP.
x86_64: doesn't handle unknown traps (idt_table entries with {0,0})

What is correct? For s390 I'd like to do a force_sig_info of some
kind, SIGBUS/BUS_OBJERR is a likely choice.

blue skies,
   Martin

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

Re: Unknown traps.

[Ralf Baechle]

On Thu, Nov 18, 2004 at 03:27:20PM +0200, Martin Schwidefsky wrote:

> Hi,
> while working on a deficiency in the illegal operation handler for
> s390 (only emits a force_sig instead of a force_sig_info) I stumbled
> over something odd: How are unknown traps handled properly?
> 
> Of the architectures where I have some clue what they are doing:
> 
> i386: doesn't handle unknown traps (idt_table entries with {0,0})
> ia64: does a force_sig with SIGILL.
> parisc: does a force_sig_info with SIGBUS/BUS_OBJERR.
> ppc: doesn't handle unknown traps (?).
> s390: does a force_sig with SIGSEGV.
> sparc: does a force_sig_info with SIGILL/ILL_ILLTRP.
> x86_64: doesn't handle unknown traps (idt_table entries with {0,0})
> 
> What is correct? For s390 I'd like to do a force_sig_info of some
> kind, SIGBUS/BUS_OBJERR is a likely choice.

I'm reacting a bit harsher on MIPS:

asmlinkage void do_reserved(struct pt_regs *regs)
{
        /*
         * Game over - no way to handle this if it ever occurs.  Most probably
         * caused by a new unknown cpu type or after another deadly
         * hard/software error.
         */
        show_regs(regs);
        panic("Caught reserved exception %ld - should not happen.",
              (regs->cp0_cause & 0x7f) >> 2);
}

If this is happening it's a severe kernel or hardware problem and it's not
clear if continuing is safe or how to recover, so game over.

  Ralf

Re: Unknown traps.

[Martin Schwidefsky]

> > What is correct? For s390 I'd like to do a force_sig_info of some
> > kind, SIGBUS/BUS_OBJERR is a likely choice.
>
> I'm reacting a bit harsher on MIPS:
>
> asmlinkage void do_reserved(struct pt_regs *regs)
> {
>         /*
>          * Game over - no way to handle this if it ever occurs.  Most
probably
>          * caused by a new unknown cpu type or after another deadly
>          * hard/software error.
>          */
>         show_regs(regs);
>         panic("Caught reserved exception %ld - should not happen.",
>               (regs->cp0_cause & 0x7f) >> 2);
> }
>
> If this is happening it's a severe kernel or hardware problem and it's
not
> clear if continuing is safe or how to recover, so game over.

Makes sense, although to panic if the fault happened in user space
is a bit too harsh, isn't it? A do_exit(SIGSEGV) if the fault took place
in user space and a panic if it happened in the kernel is my favorite
at the moment.

blue skies,
   Martin

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

Re: Unknown traps.

[Ralf Baechle]

On Wed, Nov 24, 2004 at 04:07:32PM +0100, Martin Schwidefsky wrote:

> Makes sense, although to panic if the fault happened in user space
> is a bit too harsh, isn't it? A do_exit(SIGSEGV) if the fault took place
> in user space and a panic if it happened in the kernel is my favorite
> at the moment.

There are asynchrous exceptions that can be delivered with significant
delay.  So could have been caused by kernel, peripherals or even a
previous processor.  Since for an unknown exception we by definition
don't know the cause or or state of the system after the exception or
how to clear the condition that is causing the exception I still think
panic is the right thing to do.

> blue skies,

Grey skies ...

  Ralf