linux-kernel - Re: [PATCH x86/mm 6/6] x86-64 ia32 ptrace get/putreg32 current task

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]

Message-ID: <alpine.LFD.0.9999.0711291139290.8458@woody.linux-foundation.org>
Date:	Thu, 29 Nov 2007 11:49:39 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...e.de>,
	Chuck Ebbert <cebbert@...hat.com>,
	Roland McGrath <roland@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Jeremy Fitzhardinge <jeremy@...p.org>, zach@...are.com
Subject: Re: [PATCH x86/mm 6/6] x86-64 ia32 ptrace get/putreg32 current
 task

On Thu, 29 Nov 2007, Andi Kleen wrote:
> 
> For i386 iirc Jeremy/Zach did the benchmarking and they settled
> on %fs because it was faster for something (originally it was %gs too) 

Hmm. Context switching ends up having to switch the segment that we do 
*not* use for the kernel, and the context switching can be faster for the 
case where

 (a) the segment selector is identical in both source and destination
*AND*
 (b) the selector is either zero or points to a GDT entry.

So yes, context switching can be faster for a NUL selector if both old and 
new threads use it, and in fact that's the onle case we check right now:

	/*
	 * Restore %gs if needed (which is common)
	 */
	if (prev->gs | next->gs)
		loadsegment(gs, next->gs);

for the 32-bit case. That is faster if "gs" is normally zero, since that 
means that we can avoid that loadsegment.

HOWEVER. That is actually not the right (well, "complete") conditional, 
since it's only one sub-case of the thing that matters. The right 
conditional is probably

	/*
	 * Restore %gs if needed (which is common).
	 * We can avoid it if they are identical, and
	 * point to the GDT.
	 */
	if ((prev->gs ^ next->gs) | (next->gs & 4))
		loadsegment(gs, next->gs);

At that point, we would only have to reload stuff if the user actually 
uses a local descriptor table entry (which does happen for threaded apps, 
I guess, but at least we avoid it for all the common traditional UNIX 
processes).

			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/