linux-kernel - Re: [PATCH 0/2] More i387 state save/restore work

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] [day] [month] [year] [list]

Date:	Thu, 01 Mar 2012 22:30:00 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Michael Neuling <mikey@...ling.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	anton@...ba.org
Subject: Re: [PATCH 0/2] More i387 state save/restore work

On Sun, 2012-02-19 at 17:11 -0800, Linus Torvalds wrote:
> Oh, and final comment - looking at the thing you pointed at, it looks
> much more adventurous than my x86 FP state thing.

Right, that's the main reason why I haven't merged it (yet...). I though
the added complexity and risk wasn't worth the added complexity and
risk.

But going half way there as you are doing definitely looks like a good
idea. I'll have a look when I'm done whacking the shit out of our
exception entry path :)

> I always save things unconditionally, so that I don't have to do the
> IPI or just in general care about the "oops, now I want things in
> memory, not in some random CPU FP state". So mine is just a "writeback
> cache", and only optimizes the reading things back: there is never any
> dirty state in the CPU except when the process is actively using it.
> 
> That obviously does mean that I only optimize away the restore side,
> not the save side. But it's *way* simpler, and considering that I just
> spent almost a week trying to figure out FP state save bugs, simple is
> good.

On the other hand, you seem to support FP use from random kernel
contexts such as softirq, interrupts etc... while we don't (well not
with the "normal" APIs, obviously you can always turn all IRQs off and
manually enable & save restore but that's too nasty for words).

Cheers,
Ben.


--
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/