x86/mpx: Use 32-bit-only cmpxchg() for 32-bit apps
authorDave Hansen <dave.hansen@linux.intel.com>
Sun, 7 Jun 2015 18:37:05 +0000 (11:37 -0700)
committerIngo Molnar <mingo@kernel.org>
Tue, 9 Jun 2015 10:24:33 +0000 (12:24 +0200)
commit6ac52bb4913eadfa327138b91aab5d37234a2c3b
tree0694f692896dfbc62c172b4d00ff4d2d8d4aac27
parent54587653904c552c56b9dec153d7a89063394b09
x86/mpx: Use 32-bit-only cmpxchg() for 32-bit apps

user_atomic_cmpxchg_inatomic() actually looks at sizeof(*ptr) to
figure out how many bytes to copy.  If we run it on a 64-bit
kernel with a 64-bit pointer, it will copy a 64-bit bounds
directory entry.  That's fine, except when we have 32-bit
programs with 32-bit bounds directory entries and we only *want*
32-bits.

This patch breaks the cmpxchg() operation out in to its own
function and performs the 32-bit type swizzling in there.

Note, the "64-bit" version of this code _would_ work on a
32-bit-only kernel.  The issue this patch addresses is only for
when the kernel's 'long' is mismatched from the size of the
bounds directory entry of the process we are working on.

The new helper modifies 'actual_old_val' or returns an error.
But gcc doesn't know this, so it warns about 'actual_old_val'
being unused.  Shut it up with an uninitialized_var().

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150607183705.672B115E@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
arch/x86/mm/mpx.c