From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Andi Kleen <andi@firstfloor.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Steven Rostedt <srostedt@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>,
Roland McGrath <roland@redhat.com>,
Ulrich Drepper <drepper@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Gregory Haskins <ghaskins@novell.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
"Luis Claudio R. Goncalves" <lclaudio@uudg.org>,
Clark Williams <williams@redhat.com>,
Christoph Lameter <cl@linux-foundation.org>
Subject: Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug
Date: Wed, 13 Aug 2008 18:22:22 -0700 [thread overview]
Message-ID: <48A388CE.2020404@goop.org> (raw)
In-Reply-To: <48A375E3.9090609@zytor.com>
H. Peter Anvin wrote:
> I believe this should be okay. In 32-bit mode some of the security
> and hypervisor frameworks want to set segment limits, but I don't
> believe they ever would set DS and SS inconsistently, or that we'd
> handle a #GP versus an #SS differently (segment violations on the
> stack segment are #SS, not #GP.) To be 100% sure we'd have to pick
> apart the modr/m byte to figure out what the base register is but I
> think that's total overkill.
The kernel sets ds and ss to the same selector, so they're always going
to have the same underlying descriptor.
My only concern is whether there are any locked instructions which are
explicitly using a cs: override for those odd corners of the kernel. I
don't think so.
That said, I wonder how useful it is to do the SMP->UP code transition.
How often does a kernel go from being SMP to UP in a situation where we
really care about the performance? And that won't be shortly be
becoming SMP again anyway?
J
next prev parent reply other threads:[~2008-08-14 1:22 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-07 18:20 [PATCH 0/5] ftrace: to kill a daemon Steven Rostedt
2008-08-07 18:20 ` [PATCH 1/5] ftrace: create __mcount_loc section Steven Rostedt
2008-08-07 18:20 ` [PATCH 2/5] ftrace: mcount call site on boot nops core Steven Rostedt
2008-08-07 18:20 ` [PATCH 3/5] ftrace: enable mcount recording for modules Steven Rostedt
2008-08-08 6:43 ` Rusty Russell
2008-08-08 12:51 ` Steven Rostedt
2008-08-07 18:20 ` [PATCH 4/5] ftrace: rebuild everything on change to FTRACE_MCOUNT_RECORD Steven Rostedt
2008-08-07 18:20 ` [PATCH 5/5] ftrace: enable using mcount recording on x86 Steven Rostedt
2008-08-07 18:47 ` [PATCH 0/5] ftrace: to kill a daemon Mathieu Desnoyers
2008-08-07 20:42 ` Steven Rostedt
2008-08-08 17:22 ` Mathieu Desnoyers
2008-08-08 17:36 ` Steven Rostedt
2008-08-08 17:46 ` Mathieu Desnoyers
2008-08-08 18:13 ` Steven Rostedt
2008-08-08 18:15 ` Peter Zijlstra
2008-08-08 18:21 ` Mathieu Desnoyers
2008-08-08 18:41 ` Steven Rostedt
2008-08-08 19:04 ` Linus Torvalds
2008-08-08 19:05 ` Mathieu Desnoyers
2008-08-08 23:38 ` Steven Rostedt
2008-08-09 0:23 ` Andi Kleen
2008-08-09 0:36 ` Steven Rostedt
2008-08-09 0:47 ` Jeremy Fitzhardinge
2008-08-09 0:51 ` Linus Torvalds
2008-08-09 1:25 ` Steven Rostedt
2008-08-13 6:31 ` Mathieu Desnoyers
2008-08-13 15:38 ` Mathieu Desnoyers
2008-08-13 17:52 ` Efficient x86 and x86_64 NOP microbenchmarks Mathieu Desnoyers
2008-08-13 18:27 ` Linus Torvalds
2008-08-13 18:41 ` Andi Kleen
2008-08-13 18:45 ` Avi Kivity
2008-08-13 18:51 ` Andi Kleen
2008-08-13 18:56 ` Avi Kivity
2008-08-13 19:30 ` Mathieu Desnoyers
2008-08-13 19:37 ` Andi Kleen
2008-08-13 20:01 ` Mathieu Desnoyers
2008-08-13 23:41 ` [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug Mathieu Desnoyers
2008-08-14 0:01 ` H. Peter Anvin
2008-08-14 1:13 ` Mathieu Desnoyers
2008-08-14 1:22 ` Jeremy Fitzhardinge [this message]
2008-08-14 1:26 ` Roland McGrath
2008-08-14 1:49 ` Mathieu Desnoyers
2008-08-14 3:35 ` Jeremy Fitzhardinge
2008-08-14 15:18 ` Mathieu Desnoyers
2008-08-14 16:10 ` Linus Torvalds
2008-08-14 16:13 ` H. Peter Anvin
2008-08-14 16:58 ` Mathieu Desnoyers
2008-08-14 17:05 ` Jeremy Fitzhardinge
2008-08-14 17:30 ` Mathieu Desnoyers
2008-08-14 17:43 ` Jeremy Fitzhardinge
2008-08-14 18:37 ` H. Peter Anvin
2008-08-14 18:53 ` Mathieu Desnoyers
2008-08-14 19:29 ` Jeremy Fitzhardinge
2008-08-14 20:31 ` Mathieu Desnoyers
2008-08-14 20:39 ` H. Peter Anvin
2008-08-14 21:46 ` Jeremy Fitzhardinge
2008-08-14 22:26 ` H. Peter Anvin
2008-08-14 17:17 ` H. Peter Anvin
2008-08-14 18:09 ` Mathieu Desnoyers
2008-08-14 19:49 ` Mathieu Desnoyers
2008-08-14 17:04 ` Jeremy Fitzhardinge
2008-08-14 17:18 ` H. Peter Anvin
2008-08-14 17:28 ` Jeremy Fitzhardinge
2008-08-14 17:31 ` H. Peter Anvin
2008-08-14 17:46 ` Mathieu Desnoyers
2008-08-14 17:49 ` Jeremy Fitzhardinge
2008-08-14 17:55 ` Mathieu Desnoyers
2008-08-14 18:59 ` Gregory Haskins
2008-08-15 21:34 ` Efficient x86 and x86_64 NOP microbenchmarks Steven Rostedt
2008-08-15 21:51 ` Andi Kleen
2008-08-13 19:16 ` Mathieu Desnoyers
2008-08-09 0:51 ` [PATCH 0/5] ftrace: to kill a daemon Steven Rostedt
2008-08-09 0:53 ` Roland McGrath
2008-08-09 1:13 ` Andi Kleen
2008-08-09 1:19 ` Andi Kleen
2008-08-09 1:30 ` Steven Rostedt
2008-08-09 1:55 ` Andi Kleen
2008-08-09 2:03 ` Steven Rostedt
2008-08-09 2:23 ` Andi Kleen
2008-08-09 4:12 ` Steven Rostedt
2008-08-09 0:30 ` Steven Rostedt
2008-08-11 18:21 ` Mathieu Desnoyers
2008-08-11 19:28 ` Steven Rostedt
2008-08-08 19:08 ` Jeremy Fitzhardinge
2008-08-11 2:41 ` Rusty Russell
2008-08-11 12:33 ` Steven Rostedt
2008-08-07 21:11 ` Jeremy Fitzhardinge
2008-08-07 21:29 ` Steven Rostedt
2008-08-07 22:26 ` Roland McGrath
2008-08-08 1:21 ` Steven Rostedt
2008-08-08 1:24 ` Steven Rostedt
2008-08-08 1:56 ` Steven Rostedt
2008-08-08 7:22 ` Peter Zijlstra
2008-08-08 11:31 ` Steven Rostedt
2008-08-08 4:54 ` Sam Ravnborg
2008-08-09 9:48 ` Abhishek Sagar
2008-08-09 13:01 ` Steven Rostedt
2008-08-09 15:01 ` Abhishek Sagar
2008-08-09 15:37 ` Steven Rostedt
2008-08-09 17:14 ` Abhishek Sagar
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=48A388CE.2020404@goop.org \
--to=jeremy@goop.org \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=drepper@redhat.com \
--cc=ghaskins@novell.com \
--cc=hpa@zytor.com \
--cc=lclaudio@uudg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=srostedt@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=williams@redhat.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