From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Chuck Ebbert <cebbert@redhat.com>,
Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Jeremy Fitzhardinge <jeremy@goop.org>,
zach@vmware.com
Subject: Re: [PATCH x86/mm 6/6] x86-64 ia32 ptrace get/putreg32 current task
Date: Thu, 29 Nov 2007 21:11:26 +0100 [thread overview]
Message-ID: <200711292111.26661.ak@suse.de> (raw)
In-Reply-To: <alpine.LFD.0.9999.0711291139290.8458@woody.linux-foundation.org>
> 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.
How would you catch (common) the case of them having different bases in the
GDT TLS entries? At some point the selector has to be reloaded, otherwise
it won't be picked up by the CPU.
I think the original condition is correct. You could maybe merge it with the
TLS entry rewrite and only do it if something changes there. Not
sure it is worth it though.
-Andi
> */
> 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
>
next prev parent reply other threads:[~2007-11-29 20:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-29 0:38 [PATCH x86/mm 1/6] x86-64 ia32 ptrace pt_regs cleanup Roland McGrath
2007-11-29 0:40 ` [PATCH x86/mm 2/6] x86-64 ptrace whitespace Roland McGrath
2007-11-29 0:40 ` [PATCH x86/mm 3/6] x86-32 " Roland McGrath
2007-11-29 0:41 ` [PATCH x86/mm 4/6] x86-64 ptrace get/putreg current task Roland McGrath
2007-11-29 17:39 ` Christoph Hellwig
2007-11-29 0:42 ` [PATCH x86/mm 5/6] x86-32 " Roland McGrath
2007-11-29 0:42 ` [PATCH x86/mm 6/6] x86-64 ia32 ptrace get/putreg32 " Roland McGrath
2007-11-29 17:34 ` Chuck Ebbert
2007-11-29 18:09 ` Linus Torvalds
2007-11-29 18:16 ` H. Peter Anvin
2007-11-29 18:31 ` Linus Torvalds
2007-11-29 18:45 ` H. Peter Anvin
2007-11-29 19:08 ` Linus Torvalds
2007-11-29 19:16 ` H. Peter Anvin
2007-11-29 19:27 ` Andi Kleen
2007-11-29 19:44 ` Ingo Molnar
2007-11-29 20:01 ` H. Peter Anvin
2007-12-01 23:44 ` Jeremy Fitzhardinge
2007-11-29 19:49 ` Linus Torvalds
2007-11-29 20:11 ` Andi Kleen [this message]
2007-11-29 20:23 ` Linus Torvalds
2007-11-29 18:17 ` Chuck Ebbert
2007-11-29 18:23 ` H. Peter Anvin
2007-11-29 22:25 ` Roland McGrath
2007-11-29 22:34 ` Linus Torvalds
2007-11-29 22:21 ` Roland McGrath
2007-11-29 23:00 ` Chuck Ebbert
2007-11-29 10:39 ` [PATCH x86/mm 1/6] x86-64 ia32 ptrace pt_regs cleanup Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200711292111.26661.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=cebbert@redhat.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=zach@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox