[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080812004641.GB18444@gondor.apana.org.au>
Date: Tue, 12 Aug 2008 08:46:41 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Suresh Siddha <suresh.b.siddha@...el.com>,
Ingo Molnar <mingo@...e.hu>,
Wolfgang Walter <wolfgang.walter@...m.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"viro@...IV.linux.org.uk" <viro@...iv.linux.org.uk>,
"vegard.nossum@...il.com" <vegard.nossum@...il.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes
On Mon, Aug 11, 2008 at 05:42:21PM -0700, H. Peter Anvin wrote:
>
> That's not sufficient, though, because you have to track all the state
> and how it relates to everything. You now have to track both the
> userspace FPU state and the potential kernel FPU state. The VIA
> instructions are special (in the short bus to school sense) in that they
> use a mechanism intended to protect specific state to protect -- exactly
> nothing.
Sorry, the kernel TS state is what I meant. I'm definitely not
advocating the saving of the kernel FPU state. This is only for
things like the VIA (which also exists for other processors, see
the xor SSE stuff in include/asm-x86).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists