[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080811192203.GC12788@elte.hu>
Date: Mon, 11 Aug 2008 21:22:03 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Suresh Siddha <suresh.b.siddha@...el.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
"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>,
"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
* Suresh Siddha <suresh.b.siddha@...el.com> wrote:
> Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@...m.de>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.com>
no fundamental objection to the x86 bits.
shouldnt this:
+ if (!in_interrupt())
+ return 0;
just be eliminated and the cr0/TS save/restore be made unconditional?
irq-assymetric APIs are not nice in general.
Reading/setting cr0 isnt _that_ slow. (or if it is, by how much does it
slow things down, exactly?)
Ingo
--
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