Commit f2919232 authored by Jeremy Fitzhardinge's avatar Jeremy Fitzhardinge Committed by Ingo Molnar

x86/pgtable: explain constant sign extension problem

When the _PAGE_FOO constants are defined as (1ul << _PAGE_BIT_FOO), they
become unsigned longs.  In 32-bit PAE mode, these end up being
implicitly cast to 64-bit types when used to manipulate a pte, and
because they're unsigned the top 32-bits are 0, destroying the upper
bits of the pte.

When _PAGE_FOO constants are given a signed integer type, the cast to
64-bits will sign-extend so that the upper bits are all ones,
preserving the upper pte bits in manipulations.

Explain this in a prominent place.
Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
parent 015c8dd0
......@@ -19,6 +19,11 @@
#define _PAGE_BIT_UNUSED3 11
#define _PAGE_BIT_NX 63 /* No execute: only valid after cpuid check */
/*
* Note: we use _AC(1, L) instead of _AC(1, UL) so that we get a
* sign-extended value on 32-bit with all 1's in the upper word,
* which preserves the upper pte values on 64-bit ptes:
*/
#define _PAGE_PRESENT (_AC(1, L)<<_PAGE_BIT_PRESENT)
#define _PAGE_RW (_AC(1, L)<<_PAGE_BIT_RW)
#define _PAGE_USER (_AC(1, L)<<_PAGE_BIT_USER)
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment