lkml.org 
[lkml]   [2004]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86_64 GPF handler (was: [PATCH] remove errornous semicolon)
On Wed, Nov 24, 2004 at 12:23:23AM -0500, Chuck Ebbert wrote:
> Jesper Juhl wrote:
>
> > arch/i386/kernel/traps.c: In function `do_general_protection':
> > arch/i386/kernel/traps.c:506: warning: empty body in an if-statement
> >
> > upon inspecting the code I see what looks like a mistakenly placed ";"
> >
> > if (!fixup_exception(regs)) {
> > if (notify_die(DIE_GPF, "general protection fault", regs,
> > error_code, 13, SIGSEGV) == NOTIFY_STOP);
> > return;
> > die("general protection fault", regs, error_code);
> > }
>
>
> Ouch. No matter what the notifier chain returns it will be treated
> as if it returned NOTIFY_STOP, and no kernel-mode GPF will ever reach
> the die().
>
> This bug was introduced 31 Aug 04 by prasanna@in.ibm.com during a
> kprobes update. The comments say it was ported from x86_64, so I had
> a look:
>
> /* kernel gp */
> {
> const struct exception_table_entry *fixup;
> fixup = search_exception_tables(regs->rip);
> if (fixup) {
> regs->rip = fixup->fixup;
> return;
> }
> notify_die(DIE_GPF, "general protection fault", regs, error_code,
> 13, SIGSEGV);
> die("general protection fault", regs, error_code);
> }
>
> x86_64 never checks the result of notify_die() and unconditionally does a die().
> I don't know if this is a bug or not...
>
> Andi, if this is not a bug could you explain why not?

It depends on what the debugger (or kprobes) wants. These checks
are added based on their needs. Perhaps he didn't consider it
necessary on x86-64. But why don't you ask Prasanna directly? (cc'ed)

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.038 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site