[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080809133138.GA30064@gondor.apana.org.au>
Date: Sat, 9 Aug 2008 21:31:38 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Suresh Siddha <suresh.b.siddha@...el.com>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Wolfgang Walter <wolfgang.walter@...m.de>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
"viro@...IV.linux.org.uk" <viro@...IV.linux.org.uk>,
"vegard.nossum@...il.com" <vegard.nossum@...il.com>
Subject: Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes
On Fri, Aug 08, 2008 at 04:11:21PM -0700, Suresh Siddha wrote:
>
> b) Looking deeper, do we need to disable interrupts in the kernel_fpu_begin()?
> Is there a recursive case, where interrupt context also touches FPU/SSE
> registers?
Even if there wasn't one before, there is going to be one now
because as you pointed out yourself, if we get an inbound IPsec
packet between any kernel_fpu_begin/kernel_fpu_end area, we could
get a nested kernel_fpu_end which puts us back to square one wrt
to the original race.
So clearly we need to think more about this issue.
Unless we can come up with a new solution quickly, I recommend
that we back out the FPU changes.
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