Messages in this thread | | | Date | Wed, 13 Aug 2008 17:01:39 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug |
| |
Mathieu Desnoyers wrote: > If a kernel thread is preempted in single-cpu mode right after the NOP (nop > about to be turned into a lock prefix), then we CPU hotplug a CPU, and then the > thread is scheduled back again, a SMP-unsafe atomic operation will be used on > shared SMP variables, leading to corruption. No corruption would happen in the > reverse case : going from SMP to UP is ok because we split a bit instruction > into tiny pieces, which does not present this condition. > > Changing the 0x90 (single-byte nop) currently used into a 0x3E DS segment > override prefix should fix this issue. Since the default of the atomic > instructions is to use the DS segment anyway, it should not affect the > behavior.
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.
I have a vague notion that DS: prefixes came with a penalty on older CPUs, so we may want to do this only when CPU hotplug is enabled, to avoid penalizing older embedded systems.
-hpa
| |