linux-kernel - Re: [PATCH -tip] introduce sys_membarrier(): process-wide memory barrier (v9)

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, 6 Mar 2010 11:43:26 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Nicholas Miell <nmiell@...cast.net>, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	josh@...htriplett.org, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, Valdis.Kletnieks@...edu,
	dhowells@...hat.com, linux-kernel@...r.kernel.org,
	Nick Piggin <npiggin@...e.de>,
	Chris Friesen <cfriesen@...tel.com>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH -tip] introduce sys_membarrier(): process-wide memory
 barrier (v9)

On Thu, 4 Mar 2010, Ingo Molnar wrote:
> 
> Perhaps NOFPU could do lazy context saving: clear the TS flag and only save 
> the FPU state if it's actually used by the signal handler?

If we can get that working reliably, we probably shouldn't use NOFPU at 
all, and we should just do it unconditionally. That big (and almost always 
pointless) FPU state save is a _big_ performance issue on signal handling, 
and if we can do it lazily, we should.

However, I'm not at all convinced we can do this reliably. How do we 
detect the "signal frame is dead" case with things like siglongjmp() etc?

And if we can't detect that "frame no longer exists", we can't really do 
the lazy context saving.

Now, there's _also_ the issue of the signal handler function possibly 
actually looking at the FPU state on the stack, and for that, a SA_NOFPU 
would be a good way to say "you can't do that". So it's possible that even 
if we could reliably detect the frame liveness we'd really have to use 
that new flag anyway.

But if we do need a SA_NOFPU flag, then that means that basically no app 
will use it, and it will be some special case for some really unusual 
library. So I really don't think this whole thing is worth it unless you 
could do it automatically.

(The "user accesses the frame" case _could_ possibly be handled by 
pointing the FP frame to a special faulting location, and never nesting 
the FP optimization. Nested signal handlers are unusual enough that they 
aren't worth optimizing for anyway. So I'm sure that there are possible 
solutions for "automatically just do the right thing" in theory, but I 
suspect they get rather complex)

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