Pull x86 MPX fixes from Thomas Gleixner:
 "Three updates for the new MPX infrastructure:
   - Use the proper error check in the trap handler
   - Add a proper config option for it
   - Bring documentation up to date"

* 'x86-mpx-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, mpx: Give MPX a real config option prompt
  x86, mpx: Update documentation
  x86_64/traps: Fix always true condition

Give MPX a real config option. The CPUs that support it (referenced
here):

  https://software.intel.com/en-us/forums/topic/402393

are not available publicly yet. Right now only the software emulator
provides MPX for the general public.

[ tglx: Make it default off. There is no point in having it on right
        now as no hardware and no proper tooling support are available ]

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141212183836.2569D58D@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

I was writing some MPX test programs and realized that the
current design makes it tricky.  I did something like:

	bndcfgu |= bnd_dir | BNDCFGU_ENABLE;
	xrstor();
	printf("xrstor done");
	// #BR bounds exception here
	prctl(MPX_ENABLE_MANAGEMENT);

and then compiled the app with "-fcheck-pointer-bounds -mmpx"
to enable MPX instrumentation.

The problem is that there is MPX instrumentation inserted in
to the area of the printf().  The kernel gets a bounds exception
and since management isn't yet enabled, it SIGSEGV's.

Add a bit to the documentation to explain a way around this and
where apps need to be careful.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141212183835.8C581B3E@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Pull x86 fixes from Ingo Molnar:
 "Misc fixes (mainly Andy's TLS fixes), plus a cleanup"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/tls: Disallow unusual TLS segments
  x86/tls: Validate TLS entries to protect espfix
  MAINTAINERS: Add me as x86 VDSO submaintainer
  x86/asm: Unify segment selector defines
  x86/asm: Guard against building the 32/64-bit versions of the asm-offsets*.c file directly
  x86_64, switch_to(): Load TLS descriptors before switching DS and ES
  x86/mm: Use min() instead of min_t() in the e820 printout code
  x86/mm: Fix zone ranges boot printout
  x86/doc: Update documentation after file shuffling

While at it, also refer to the 32 bit entry file.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: linux-doc@vger.kernel.org
Cc: bpoirier@suse.de
Link: http://lkml.kernel.org/r/1418165684-6226-1-git-send-email-mcgrof@do-not-panic.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

This patch adds the Documentation/x86/intel_mpx.txt file with some
information about Intel MPX.

Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151832.7FDB1720@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Peter Anvin says:

 > 0xffff880000000000 is the lowest usable address because we have
 > agreed to leave 0xffff800000000000-0xffff880000000000 for the
 > hypervisor or other non-OS uses.

Let's call this out in the documentation.

This came up during the kernel address sanitizer discussions
where it was proposed to use this area for other kernel things.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Link: http://lkml.kernel.org/r/20140918195606.841389D2@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Fix the documented sysconfig location of 'tlb_single_page_flush_ceiling'
which is under /sys/kernel/debug/... not /sys/debug/kernel/...

Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Link: http://lkml.kernel.org/r/1407484195-1441-1-git-send-email-jmmahler@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Most of the logic here is in the documentation file.  Please take
a look at it.

I know we've come full-circle here back to a tunable, but this
new one is *WAY* simpler.  I challenge anyone to describe in one
sentence how the old one worked.  Here's the way the new one
works:

	If we are flushing more pages than the ceiling, we use
	the full flush, otherwise we use per-page flushes.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: http://lkml.kernel.org/r/20140731154101.12B52CAF@viggo.jf.intel.com
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

Pull x86-64 espfix changes from Peter Anvin:
 "This is the espfix64 code, which fixes the IRET information leak as
  well as the associated functionality problem.  With this code applied,
  16-bit stack segments finally work as intended even on a 64-bit
  kernel.

  Consequently, this patchset also removes the runtime option that we
  added as an interim measure.

  To help the people working on Linux kernels for very small systems,
  this patchset also makes these compile-time configurable features"

* 'x86/espfix' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  Revert "x86-64, modify_ldt: Make support for 16-bit segments a runtime option"
  x86, espfix: Make it possible to disable 16-bit support
  x86, espfix: Make espfix64 a Kconfig option, fix UML
  x86, espfix: Fix broken header guard
  x86, espfix: Move espfix definitions into a separate header file
  x86-32, espfix: Remove filter for espfix32 due to race
  x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack