lkml.org 
[lkml]   [2019]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch V2 03/17] x86/traps: Remove pointless irq enable from do_spurious_interrupt_bug()
On Thu, Oct 24, 2019 at 12:35:27AM +0200, Thomas Gleixner wrote:
> On Wed, 23 Oct 2019, Josh Poimboeuf wrote:
>
> > On Wed, Oct 23, 2019 at 02:27:08PM +0200, Thomas Gleixner wrote:
> > > That function returns immediately after conditionally reenabling interrupts which
> > > is more than pointless and requires the ASM code to disable interrupts again.
> > >
> > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > > ---
> > > arch/x86/kernel/traps.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > --- a/arch/x86/kernel/traps.c
> > > +++ b/arch/x86/kernel/traps.c
> > > @@ -871,7 +871,6 @@ do_simd_coprocessor_error(struct pt_regs
> > > dotraplinkage void
> > > do_spurious_interrupt_bug(struct pt_regs *regs, long error_code)
> > > {
> > > - cond_local_irq_enable(regs);
> > > }
> >
> > I think we can just remove this handler altogether. The Intel and AMD
> > manuals say vector 15 (X86_TRAP_SPURIOUS) is reserved.
>
> Right, but this has history. Pentium Pro Erratum:
>
> PROBLEM: If the APIC subsystem is configured in mixed mode with Virtual
> Wire mode implemented through the local APIC, an interrupt vector of 0Fh
> (Intel reserved encoding) may be generated by the local APIC (Int 15).
> This vector may be generated upon receipt of a spurious interrupt (an
> interrupt which is removed before the system receives the INTA sequence)
> instead of the programmed 8259 spurious interrupt vector.
>
> IMPLICATION: The spurious interrupt vector programmed in the 8259 is
> normally handled by an operating system’s spurious interrupt
> handler. However, a vector of 0Fh is unknown to some operating systems,
> which would crash if this erratum occurred.
>
> Initially (2.1.) there was a printk() in that handler, which later got
> ifdeffed out (2.1.54).
>
> So I rather keep that thing at least as long as we support PPro :) Even if
> we ditch that the handler is not really hurting anyone.

Ah. I guess we could remove the idtentry for 64-bit then? Anyway the
above would be a good comment for the function.

--
Josh

\
 
 \ /
  Last update: 2019-10-24 00:50    [W:1.942 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site