[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxztx=Cf8i+jZE=X8Zx1BZnNpC6wv-PkWcXDfBFS6qWqg@mail.gmail.com>
Date: Thu, 23 Feb 2012 14:38:42 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Willy Tarreau <w@....eu>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"H. Peter Anvin" <hpa@...or.com>, stable@...r.kernel.org,
Raphael Prevost <raphael@...o.asia>,
Suresh Siddha <suresh.b.siddha@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] i387: stable kernel backport
On Thu, Feb 23, 2012 at 2:27 PM, Willy Tarreau <w@....eu> wrote:
>
> OK so indeed I will only be able to check that it boots :-/
Well, we could do some trivial test-harness that just forces the issue
with regular timer interrupts (and even without AES-NI). I think Peter
talked about that when we were trying to hunt it down - but I think he
was then able to reproduce the problem without anything special and we
dropped it.
Essentially, just doing something like
if (irq_fpu_usable()) {
kernel_fpu_begin();
kernel_fpu_end();
}
in do_irq() and do_softirq() would stress-test things even without
wireless, and even without AES-NI.
You'd still need an x86-32 machine to test on, because x86-64 was
immune to this issue.
But yeah, the impact of this seems to be small enough that for older
kernels (which are likely used on older systems for maintenance
anyway) disabling AES-NI on x86-32 really might be the way to go.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists