Re: [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptiblekernel and CPU hotplug

[H. Peter Anvin]

Mathieu Desnoyers wrote:
> I'm just worried about this comment from Harvey Harrison :
>
> arch/x86/mm/fault.c : is_prefetch()
>
>                          * Values 0x26,0x2E,0x36,0x3E are valid x86 prefixes.
>                          * In X86_64 long mode, the CPU will signal invalid
>                          * opcode if some of these prefixes are present so
>                          * X86_64 will never get here anyway
>                          */
>
> This comment refers to :
>
> 0x26 : ES segment override prefix
> 0x2E : CS segment override prefix
> 0x36 : SS segment override prefix
> 0x3E : DS segment override prefix
>
> AMD documentation seems to indicate that these prefix will be null, not
> that the cpu would signal "invalid opcodes" :
>
> "AMD 64-Bit Technology" A.7
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/x86-64_overview.pdf
>
> "In 64-bit mode, the DS, ES, SS and CS segment-override prefixes have no effect.
> These four prefixes are no longer treated as segment-override prefixes in the
> context of multipleprefix rules. Instead, they are treated as null prefixes."
>
> Intel does not seem to state anything particular about these prefixes
> for the 64-bit mode.
>
> So, is this comment misleading, or is it using the term "invalid opcode"
> in a way that does not imply generating a fault ?

They do not signal faults, there just aren't any base addresses behind 
them.  Some AMD chips allow limits to be set on these segments -- 
apparently added on behalf of some hypervisor makers; I suspect that 
VMX/SVM is making that quickly obsolete.

So it should be just fine.

Acked-by: H. Peter Anvin <hpa@xxxxxxxxx>

	-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/