Messages in this thread | | | Date | Sun, 10 Aug 2008 11:05:21 +0800 | From | Herbert Xu <> | Subject | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes |
| |
On Sat, Aug 09, 2008 at 12:37:24PM -0700, Suresh Siddha wrote: > On Sat, Aug 09, 2008 at 11:52:24AM -0700, Siddha, Suresh B wrote: > > Backing out lazy allocation is not just enough here. Let me think a little > > more on this. > > Can we have something like irq_ts_save() and irq_ts_restore(), which will > do something like: > > int irq_ts_save() > { > if (!in_interrupt()) > return 0; > > if (read_cr0() & X86_CR0_TS) { > clts(); > return 1; > } > return 0; > } > > void irq_ts_restore(int TS_state) > { > if (!in_interrupt()) > return 0;
This check isn't necessary.
> > if (TS_state) > stts(); > }
But yes this scheme looks good to me.
> kernel_fpu_begin: > ... > > local_irq_disable(); > > if (me->status & TS_USEDFPU) > __save_init_fpu(me->task); > else > clts(); > > local_irq_enable(); > ...
Couldn't we just move clts before the USEDFPU check? That huld close the window.
Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
| |