linux-kernel - Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 Feb 2015 10:31:50 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Oleg Nesterov <oleg@...hat.com>, Rik van Riel <riel@...hat.com>,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs


* Andy Lutomirski <luto@...capital.net> wrote:

> We have eager and lazy fpu modes, introduced in:
> 
> 304bceda6a18 x86, fpu: use non-lazy fpu restore for processors supporting xsave
> 
> The result is rather messy.  There are two code paths in 
> almost all of the FPU code, and only one of them (the 
> eager case) is tested frequently, since most kernel 
> developers have new enough hardware that we use eagerfpu.
> 
> It seems that, on any remotely recent hardware, eagerfpu 
> is a win: glibc uses SSE2, so laziness is probably 
> overoptimistic, and, in any case, manipulating TS is far 
> slower that saving and restoring the full state.
> 
> To try to shake out any latent issues on old hardware, 
> this changes the default to eager on all CPUs.  If no 
> performance or functionality problems show up, a 
> subsequent patch could remove lazy mode entirely.

So it would be nice to test this on at least one reasonably 
old (but not uncomfortably old - say 5 years old) system, 
to get a feel for what kind of performance impact it has 
there.

But yes, this would enable a nice simplification in the end 
so I'm all for it as long as it doesn't cause unacceptable 
problems - and the FPU code needs simplification badly, 
because the current latency of bug discovery is too high 
IMO.

Thanks,

	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/