1. 11 Aug, 2016 8 commits
    • Andy Lutomirski's avatar
      x86/efi: Allocate a trampoline if needed in efi_free_boot_services() · 5bc653b7
      Andy Lutomirski authored
      On my Dell XPS 13 9350 with firmware 1.4.4 and SGX on, if I boot
      Fedora 24's grub2-efi off a hard disk, my first 1MB of RAM looks
      like:
      
       efi: mem00: [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000000000-0x0000000000000fff] (0MB)
       efi: mem01: [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000001000-0x0000000000027fff] (0MB)
       efi: mem02: [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000028000-0x0000000000029fff] (0MB)
       efi: mem03: [Reserved           |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002a000-0x000000000002bfff] (0MB)
       efi: mem04: [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002c000-0x000000000002cfff] (0MB)
       efi: mem05: [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002d000-0x000000000002dfff] (0MB)
       efi: mem06: [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002e000-0x0000000000057fff] (0MB)
       efi: mem07: [Reserved           |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000058000-0x0000000000058fff] (0MB)
       efi: mem08: [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000059000-0x000000000009ffff] (0MB)
      
      My EBDA is at 0x2c000, which blocks off everything from 0x2c000 and
      up, and my trampoline is 0x6000 bytes (6 pages), so it doesn't fit
      in the loader data range at 0x28000.
      
      Without this patch, it panics due to a failure to allocate the
      trampoline.  With this patch, it works:
      
       [  +0.001744] Base memory trampoline at [ffff880000001000] 1000 size 24576
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mario Limonciello <mario_limonciello@dell.com>
      Cc: Matt Fleming <mfleming@suse.de>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/998c77b3bf709f3dfed85cb30701ed1a5d8a438b.1470821230.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5bc653b7
    • Andy Lutomirski's avatar
      x86/boot: Rework reserve_real_mode() to allow multiple tries · 5ff3e2c3
      Andy Lutomirski authored
      If reserve_real_mode() fails, panicing immediately means we're
      doomed.  Make it safe to try more than once to allocate the
      trampoline:
      
       - Degrade a failure from panic() to pr_info().  (If we make it to
         setup_real_mode() without reserving the trampoline, we'll panic
         them.)
      
       - Factor out helpers so that platform code can supply a specific
         address to try.
      
       - Warn if reserve_real_mode() is called after we're done with the
         memblock allocator.  If that were to happen, we would behave
         unpredictably.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mario Limonciello <mario_limonciello@dell.com>
      Cc: Matt Fleming <mfleming@suse.de>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/876e383038f3e9971aa72fd20a4f5da05f9d193d.1470821230.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5ff3e2c3
    • Andy Lutomirski's avatar
      x86/boot: Defer setup_real_mode() to early_initcall time · d0de0f68
      Andy Lutomirski authored
      There's no need to run setup_real_mode() as early as we run it.
      Defer it to the same early_initcall that sets up the page
      permissions for the real mode code.
      
      This should be a code size reduction.  More importantly, it give us
      a longer window in which we can allocate the real mode trampoline.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mario Limonciello <mario_limonciello@dell.com>
      Cc: Matt Fleming <mfleming@suse.de>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/fd62f0da4f79357695e9bf3e365623736b05f119.1470821230.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d0de0f68
    • Andy Lutomirski's avatar
      x86/boot: Synchronize trampoline_cr4_features and mmu_cr4_features directly · 18bc7bd5
      Andy Lutomirski authored
      The initialization process for trampoline_cr4_features and
      mmu_cr4_features was confusing.  The intent is for mmu_cr4_features
      and *trampoline_cr4_features to stay in sync, but
      trampoline_cr4_features is NULL until setup_real_mode() runs.  The
      old code synchronized *trampoline_cr4_features *twice*, once in
      setup_real_mode() and once in setup_arch().  It also initialized
      mmu_cr4_features in setup_real_mode(), which causes the actual value
      of mmu_cr4_features to potentially depend on when setup_real_mode()
      is called.
      
      With this patch, mmu_cr4_features is initialized directly in
      setup_arch(), and *trampoline_cr4_features is synchronized to
      mmu_cr4_features when the trampoline is set up.
      
      After this patch, it should be safe to defer setup_real_mode().
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mario Limonciello <mario_limonciello@dell.com>
      Cc: Matt Fleming <mfleming@suse.de>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/d48a263f9912389b957dd495a7127b009259ffe0.1470821230.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      18bc7bd5
    • Andy Lutomirski's avatar
      x86/boot: Run reserve_bios_regions() after we initialize the memory map · 007b7560
      Andy Lutomirski authored
      reserve_bios_regions() is a quirk that reserves memory that we might
      otherwise think is available.  There's no need to run it so early,
      and running it before we have the memory map initialized with its
      non-quirky inputs makes it hard to make reserve_bios_regions() more
      intelligent.
      
      Move it right after we populate the memblock state.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mario Limonciello <mario_limonciello@dell.com>
      Cc: Matt Fleming <mfleming@suse.de>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/59f58618911005c799c6c9979ce6ae4881d907c2.1470821230.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      007b7560
    • Aaron Lu's avatar
      x86/irq: Do not substract irq_tlb_count from irq_call_count · 82ba4fac
      Aaron Lu authored
      Since commit:
      
        52aec330 ("x86/tlb: replace INVALIDATE_TLB_VECTOR by CALL_FUNCTION_VECTOR")
      
      the TLB remote shootdown is done through call function vector. That
      commit didn't take care of irq_tlb_count, which a later commit:
      
        fd0f5869 ("x86: Distinguish TLB shootdown interrupts from other functions call interrupts")
      
      ... tried to fix.
      
      The fix assumes every increase of irq_tlb_count has a corresponding
      increase of irq_call_count. So the irq_call_count is always bigger than
      irq_tlb_count and we could substract irq_tlb_count from irq_call_count.
      
      Unfortunately this is not true for the smp_call_function_single() case.
      The IPI is only sent if the target CPU's call_single_queue is empty when
      adding a csd into it in generic_exec_single. That means if two threads
      are both adding flush tlb csds to the same CPU's call_single_queue, only
      one IPI is sent. In other words, the irq_call_count is incremented by 1
      but irq_tlb_count is incremented by 2. Over time, irq_tlb_count will be
      bigger than irq_call_count and the substract will produce a very large
      irq_call_count value due to overflow.
      
      Considering that:
      
        1) it's not worth to send more IPIs for the sake of accurate counting of
           irq_call_count in generic_exec_single();
      
        2) it's not easy to tell if the call function interrupt is for TLB
           shootdown in __smp_call_function_single_interrupt().
      
      Not to exclude TLB shootdown from call function count seems to be the
      simplest fix and this patch just does that.
      
      This bug was found by LKP's cyclic performance regression tracking recently
      with the vm-scalability test suite. I have bisected to commit:
      
        3dec0ba0 ("mm/rmap: share the i_mmap_rwsem")
      
      This commit didn't do anything wrong but revealed the irq_call_count
      problem. IIUC, the commit makes rwc->remap_one in rmap_walk_file
      concurrent with multiple threads.  When remap_one is try_to_unmap_one(),
      then multiple threads could queue flush TLB to the same CPU but only
      one IPI will be sent.
      
      Since the commit was added in Linux v3.19, the counting problem only
      shows up from v3.19 onwards.
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Cc: Alex Shi <alex.shi@linaro.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
      Link: http://lkml.kernel.org/r/20160811074430.GA18163@aaronlu.sh.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      82ba4fac
    • Dave Hansen's avatar
      x86/mm: Fix swap entry comment and macro · ace7fab7
      Dave Hansen authored
      A recent patch changed the format of a swap PTE.
      
      The comment explaining the format of the swap PTE is wrong about
      the bits used for the swap type field.  Amusingly, the ASCII art
      and the patch description are correct, but the comment itself
      is wrong.
      
      As I was looking at this, I also noticed that the
      SWP_OFFSET_FIRST_BIT has an off-by-one error.  This does not
      really hurt anything.  It just wasted a bit of space in the PTE,
      giving us 2^59 bytes of addressable space in our swapfiles
      instead of 2^60.  But, it doesn't match with the comments, and it
      wastes a bit of space, so fix it.
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Fixes: 00839ee3 ("x86/mm: Move swap offset/type up in PTE to work around erratum")
      Link: http://lkml.kernel.org/r/20160810172325.E56AD7DA@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ace7fab7
    • Nicolas Iooss's avatar
      x86/mm/kaslr: Fix -Wformat-security warning · 62d16b5a
      Nicolas Iooss authored
      debug_putstr() is used to output strings without using printf-like
      formatting but debug_putstr(v) is defined as early_printk(v) in
      arch/x86/lib/kaslr.c.
      
      This makes clang reports the following warning when building
      with -Wformat-security:
      
          arch/x86/lib/kaslr.c:57:15: warning: format string is not a string
          literal (potentially insecure) [-Wformat-security]
                  debug_putstr(purpose);
                               ^~~~~~~
      
      Fix this by using "%s" in early_printk().
      Signed-off-by: default avatarNicolas Iooss <nicolas.iooss_linux@m4x.org>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160806102039.27221-1-nicolas.iooss_linux@m4x.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      62d16b5a
  2. 10 Aug, 2016 11 commits
    • Dave Hansen's avatar
      x86/mm/pkeys: Fix compact mode by removing protection keys' XSAVE buffer manipulation · b79daf85
      Dave Hansen authored
      The Memory Protection Keys "rights register" (PKRU) is
      XSAVE-managed, and is saved/restored along with the FPU state.
      
      When kernel code accesses FPU regsisters, it does a delicate
      dance with preempt.  Otherwise, the context switching code can
      get confused as to whether the most up-to-date state is in the
      registers themselves or in the XSAVE buffer.
      
      But, PKRU is not a normal FPU register.  Using it does not
      generate the normal device-not-available (#NM) exceptions which
      means we can not manage it lazily, and the kernel completley
      disallows using lazy mode when it is enabled.
      
      The dance with preempt *only* occurs when managing the FPU
      lazily.  Since we never manage PKRU lazily, we do not have to do
      the dance with preempt; we can access it directly.  Doing it
      this way saves a ton of complicated code (and is faster too).
      
      Further, the XSAVES reenabling failed to patch a bit of code
      in fpu__xfeature_set_state() the checked for compacted buffers.
      That check caused fpu__xfeature_set_state() to silently refuse to
      work when the kernel is using compacted XSAVE buffers.  This
      broke execute-only and future pkey_mprotect() support when using
      compact XSAVE buffers.
      
      But, removing fpu__xfeature_set_state() gets rid of this issue,
      in addition to the nice cleanup and speedup.
      
      This fixes the same thing as a fix that Sai posted:
      
        https://lkml.org/lkml/2016/7/25/637
      
      The fix that he posted is a much more obviously correct, but I
      think we should just do this instead.
      Reported-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Ravi Shankar <ravi.v.shankar@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yu-Cheng Yu <yu-cheng.yu@intel.com>
      Link: http://lkml.kernel.org/r/20160727232040.7D060DAD@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b79daf85
    • Valdis Kletnieks's avatar
      x86/build: Reduce the W=1 warnings noise when compiling x86 syscall tables · 5e44258d
      Valdis Kletnieks authored
      Building an X86_64 kernel with W=1 throws a total of 9,948 lines of warnings of
      this form for both 32-bit and 64-bit syscall tables. Given that the entire rest
      of the build for my config only generates 8,375 lines of output, this is a big
      reduction in the warnings generated.
      
      The warnings follow this pattern:
      
        ./arch/x86/include/generated/asm/syscalls_32.h:885:21: warning: initialized field overwritten [-Woverride-init]
         __SYSCALL_I386(379, compat_sys_pwritev2, )
                           ^
        arch/x86/entry/syscall_32.c:13:46: note: in definition of macro '__SYSCALL_I386'
         #define __SYSCALL_I386(nr, sym, qual) [nr] = sym,
                                                    ^~~
        ./arch/x86/include/generated/asm/syscalls_32.h:885:21: note: (near initialization for 'ia32_sys_call_table[379]')
         __SYSCALL_I386(379, compat_sys_pwritev2, )
                           ^
        arch/x86/entry/syscall_32.c:13:46: note: in definition of macro '__SYSCALL_I386'
         #define __SYSCALL_I386(nr, sym, qual) [nr] = sym,
      
      Since we intentionally build the syscall tables this way, ignore that one
      warning in the two files.
      Signed-off-by: default avatarValdis Kletnieks <valdis.kletnieks@vt.edu>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/7464.1470021890@turing-police.cc.vt.eduSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5e44258d
    • Mike Travis's avatar
      x86/platform/UV: Fix kernel panic running RHEL kdump kernel on UV systems · 5a52e8f8
      Mike Travis authored
      The latest UV kernel support panics when RHEL7 kexec's the kdump kernel
      to make a dumpfile.  This patch fixes the problem by turning off all UV
      support if NUMA is off.
      Tested-by: default avatarFrank Ramsay <framsay@sgi.com>
      Tested-by: default avatarJohn Estabrook <estabrook@sgi.com>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Reviewed-by: default avatarDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: default avatarNathan Zimmer <nzimmer@sgi.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andrew Banman <abanman@sgi.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russ Anderson <rja@sgi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160801184050.577755634@asylum.americas.sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5a52e8f8
    • Mike Travis's avatar
      x86/platform/UV: Fix problem with UV4 BIOS providing incorrect PXM values · 22ac2bca
      Mike Travis authored
      There are some circumstances where the UV4 BIOS cannot provide the
      correct Proximity Node values to associate with specific Sockets and
      Physical Nodes.  The decision was made to remove these values from BIOS
      and for the kernel to get these values from the standard ACPI tables.
      Tested-by: default avatarFrank Ramsay <framsay@sgi.com>
      Tested-by: default avatarJohn Estabrook <estabrook@sgi.com>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Reviewed-by: default avatarDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: default avatarNathan Zimmer <nzimmer@sgi.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andrew Banman <abanman@sgi.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russ Anderson <rja@sgi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160801184050.414210079@asylum.americas.sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      22ac2bca
    • Mike Travis's avatar
      x86/platform/UV: Fix bug with iounmap() of the UV4 EFI System Table causing a crash · e363d24c
      Mike Travis authored
      Save the uv_systab::size field before doing the iounmap()
      of the struct pointer, to avoid a NULL dereference crash.
      Tested-by: default avatarFrank Ramsay <framsay@sgi.com>
      Tested-by: default avatarJohn Estabrook <estabrook@sgi.com>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Reviewed-by: default avatarDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: default avatarNathan Zimmer <nzimmer@sgi.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andrew Banman <abanman@sgi.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russ Anderson <rja@sgi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160801184050.250424783@asylum.americas.sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e363d24c
    • Mike Travis's avatar
      x86/platform/UV: Fix problem with UV4 Socket IDs not being contiguous · 054f621f
      Mike Travis authored
      The UV4 Socket IDs are not guaranteed to equate to Node values which
      can cause the GAM (Global Addressable Memory) table lookups to fail.
      Fix this by using an independent index into the GAM table instead of
      the Socket ID to reference the base address.
      Tested-by: default avatarFrank Ramsay <framsay@sgi.com>
      Tested-by: default avatarJohn Estabrook <estabrook@sgi.com>
      Signed-off-by: default avatarMike Travis <travis@sgi.com>
      Reviewed-by: default avatarDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: default avatarNathan Zimmer <nzimmer@sgi.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andrew Banman <abanman@sgi.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russ Anderson <rja@sgi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160801184050.048755337@asylum.americas.sgi.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      054f621f
    • Borislav Petkov's avatar
      x86/entry: Clarify the RF saving/restoring situation with SYSCALL/SYSRET · 3e035305
      Borislav Petkov authored
      Clarify why exactly RF cannot be restored properly by SYSRET to avoid
      confusion.
      
      No functionality change.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160803171429.GA2590@nazgul.tnicSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3e035305
    • Sebastian Andrzej Siewior's avatar
      x86/mm: Disable preemption during CR3 read+write · 5cf0791d
      Sebastian Andrzej Siewior authored
      There's a subtle preemption race on UP kernels:
      
      Usually current->mm (and therefore mm->pgd) stays the same during the
      lifetime of a task so it does not matter if a task gets preempted during
      the read and write of the CR3.
      
      But then, there is this scenario on x86-UP:
      
      TaskA is in do_exit() and exit_mm() sets current->mm = NULL followed by:
      
       -> mmput()
       -> exit_mmap()
       -> tlb_finish_mmu()
       -> tlb_flush_mmu()
       -> tlb_flush_mmu_tlbonly()
       -> tlb_flush()
       -> flush_tlb_mm_range()
       -> __flush_tlb_up()
       -> __flush_tlb()
       ->  __native_flush_tlb()
      
      At this point current->mm is NULL but current->active_mm still points to
      the "old" mm.
      
      Let's preempt taskA _after_ native_read_cr3() by taskB. TaskB has its
      own mm so CR3 has changed.
      
      Now preempt back to taskA. TaskA has no ->mm set so it borrows taskB's
      mm and so CR3 remains unchanged. Once taskA gets active it continues
      where it was interrupted and that means it writes its old CR3 value
      back. Everything is fine because userland won't need its memory
      anymore.
      
      Now the fun part:
      
      Let's preempt taskA one more time and get back to taskB. This
      time switch_mm() won't do a thing because oldmm (->active_mm)
      is the same as mm (as per context_switch()). So we remain
      with a bad CR3 / PGD and return to userland.
      
      The next thing that happens is handle_mm_fault() with an address for
      the execution of its code in userland. handle_mm_fault() realizes that
      it has a PTE with proper rights so it returns doing nothing. But the
      CPU looks at the wrong PGD and insists that something is wrong and
      faults again. And again. And one more time…
      
      This pagefault circle continues until the scheduler gets tired of it and
      puts another task on the CPU. It gets little difficult if the task is a
      RT task with a high priority. The system will either freeze or it gets
      fixed by the software watchdog thread which usually runs at RT-max prio.
      But waiting for the watchdog will increase the latency of the RT task
      which is no good.
      
      Fix this by disabling preemption across the critical code section.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1470404259-26290-1-git-send-email-bigeasy@linutronix.de
      [ Prettified the changelog. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5cf0791d
    • Thomas Garnier's avatar
      x86/mm/KASLR: Increase BRK pages for KASLR memory randomization · fb754f95
      Thomas Garnier authored
      Default implementation expects 6 pages maximum are needed for low page
      allocations. If KASLR memory randomization is enabled, the worse case
      of e820 layout would require 12 pages (no large pages). It is due to the
      PUD level randomization and the variable e820 memory layout.
      
      This bug was found while doing extensive testing of KASLR memory
      randomization on different type of hardware.
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Cc: Aleksey Makarov <aleksey.makarov@linaro.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Lv Zheng <lv.zheng@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: kernel-hardening@lists.openwall.com
      Fixes: 021182e5 ("Enable KASLR for physical mapping memory regions")
      Link: http://lkml.kernel.org/r/1470762665-88032-2-git-send-email-thgarnie@google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      fb754f95
    • Thomas Garnier's avatar
      x86/mm/KASLR: Fix physical memory calculation on KASLR memory randomization · c7d2361f
      Thomas Garnier authored
      Initialize KASLR memory randomization after max_pfn is initialized. Also
      ensure the size is rounded up. It could create problems on machines
      with more than 1Tb of memory on certain random addresses.
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Cc: Aleksey Makarov <aleksey.makarov@linaro.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Lv Zheng <lv.zheng@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: kernel-hardening@lists.openwall.com
      Fixes: 021182e5 ("Enable KASLR for physical mapping memory regions")
      Link: http://lkml.kernel.org/r/1470762665-88032-1-git-send-email-thgarnie@google.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c7d2361f
    • Alexander Potapenko's avatar
      x86, kasan, ftrace: Put APIC interrupt handlers into .irqentry.text · 469f0023
      Alexander Potapenko authored
      Dmitry Vyukov has reported unexpected KASAN stackdepot growth:
      
        https://github.com/google/kasan/issues/36
      
      ... which is caused by the APIC handlers not being present in .irqentry.text:
      
      When building with CONFIG_FUNCTION_GRAPH_TRACER=y or CONFIG_KASAN=y, put the
      APIC interrupt handlers into the .irqentry.text section. This is needed
      because both KASAN and function graph tracer use __irqentry_text_start and
      __irqentry_text_end to determine whether a function is an IRQ entry point.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: aryabinin@virtuozzo.com
      Cc: kasan-dev@googlegroups.com
      Cc: kcc@google.com
      Cc: rostedt@goodmis.org
      Link: http://lkml.kernel.org/r/1468575763-144889-1-git-send-email-glider@google.com
      [ Minor edits. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      469f0023
  3. 09 Aug, 2016 14 commits
    • Linus Torvalds's avatar
      Revert "printk: create pr_<level> functions" · a0cba217
      Linus Torvalds authored
      This reverts commit 874f9c7d.
      
      Geert Uytterhoeven reports:
       "This change seems to have an (unintendent?) side-effect.
      
        Before, pr_*() calls without a trailing newline characters would be
        printed with a newline character appended, both on the console and in
        the output of the dmesg command.
      
        After this commit, no new line character is appended, and the output
        of the next pr_*() call of the same type may be appended, like in:
      
          - Truncating RAM at 0x0000000040000000-0x00000000c0000000 to -0x0000000070000000
          - Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)
          + Truncating RAM at 0x0000000040000000-0x00000000c0000000 to -0x0000000070000000Ignoring RAM at 0x0000000200000000-0x0000000240000000 (!CONFIG_HIGHMEM)"
      
      Joe Perches says:
       "No, that is not intentional.
      
        The newline handling code inside vprintk_emit is a bit involved and
        for now I suggest a revert until this has all the same behavior as
        earlier"
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Requested-by: default avatarJoe Perches <joe@perches.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a0cba217
    • Linus Torvalds's avatar
      Merge tag 'trace-v4.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 84bd8d33
      Linus Torvalds authored
      Pull tracing fix from Steven Rostedt:
       "Fix tick_stop tracepoint symbols for user export.
      
        Luiz Capitulino noticed that the tick_stop tracepoint wasn't being
        parsed properly by the tracing user space tools.
      
        This was due to the TRACE_DEFINE_ENUM() being set to a define, when it
        should have been set to the enum itself.  The define was of the MASK
        that used the BIT to shift.  The BIT was the enum and by adding that,
        everything gets converted nicely.  The MASK is still kept just in case
        it gets converted to an enum in the future"
      
      * tag 'trace-v4.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Fix tick_stop tracepoint symbols for user export
      84bd8d33
    • Linus Torvalds's avatar
      Merge tag 'gcc-plugin-infrastructure-v4.8-rc2' of... · b79f34d6
      Linus Torvalds authored
      Merge tag 'gcc-plugin-infrastructure-v4.8-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
      
      Pull gcc plugin improvements from Kees Cook:
       "Several fixes/improvements for the gcc plugin infrastructure:
      
         - fix a problem with gcc plugins interfering with cc-option tests.
      
         - abort more gracefully when gcc plugin headers or compiler support
           is missing.
      
         - improve the gcc plugin rule generation to be more dynamic, pass
           arguments, and build from subdirectories"
      
      * tag 'gcc-plugin-infrastructure-v4.8-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        gcc-plugins: Add support for plugin subdirectories
        gcc-plugins: Automate make rule generation
        gcc-plugins: Add support for passing plugin arguments
        gcc-plugins: abort builds cleanly when not supported
        kbuild: no gcc-plugins during cc-option tests
      b79f34d6
    • Linus Torvalds's avatar
      Merge tag 'platform-drivers-x86-v4.8-3' of... · e1d009ea
      Linus Torvalds authored
      Merge tag 'platform-drivers-x86-v4.8-3' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
      
      Pull x86 platform driver update from Darren Hart:
       "dell-wmi: ignore battery remove/insert event"
      
      * tag 'platform-drivers-x86-v4.8-3' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
        dell-wmi: Ignore WMI event 0xe00e
      e1d009ea
    • Linus Torvalds's avatar
      Merge tag 'drm-fixes-for-4.8-rc2' of git://people.freedesktop.org/~airlied/linux · cb0d93aa
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "This contains a bunch of amdgpu fixes, and some i915 regression fixes.
      
        It also contains some fixes for an older regression with some EDID
        changes and some 6bpc panels.
      
        Then there are the lockdep, cirrus and rcar-du regression fixes from
        this window"
      
      * tag 'drm-fixes-for-4.8-rc2' of git://people.freedesktop.org/~airlied/linux:
        drm/cirrus: Fix NULL pointer dereference when registering the fbdev
        drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS".
        drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"
        drm/edid: Add 6 bpc quirk for display AEO model 0.
        drm: Paper over locking inversion after registration rework
        drm: rcar-du: Link HDMI encoder with bridge
        drm/ttm: Wait for a BO to become idle before unbinding it from GTT
        drm/i915/fbdev: Check for the framebuffer before use
        drm/amdgpu: update golden setting of polaris10
        drm/amdgpu: update golden setting of stoney
        drm/amdgpu: update golden setting of polaris11
        drm/amdgpu: update golden setting of carrizo
        drm/amdgpu: update golden setting of iceland
        drm/amd/amdgpu: change pptable output format from ASCII to binary
        drm/amdgpu/ci: add mullins to default case for smc ucode
        drm/amdgpu/gmc7: add missing mullins case
        drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB
        drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
      cb0d93aa
    • Brian King's avatar
      ipr: Fix sync scsi scan · a3d1ddd9
      Brian King authored
      Commit b195d5e2 ("ipr: Wait to do async scan until scsi host is
      initialized") fixed async scan for ipr, but broke sync scan for ipr.
      
      This fixes sync scan back up.
      Signed-off-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Reported-and-tested-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a3d1ddd9
    • Vladimir Davydov's avatar
      mm: memcontrol: only mark charged pages with PageKmemcg · c4159a75
      Vladimir Davydov authored
      To distinguish non-slab pages charged to kmemcg we mark them PageKmemcg,
      which sets page->_mapcount to -512.  Currently, we set/clear PageKmemcg
      in __alloc_pages_nodemask()/free_pages_prepare() for any page allocated
      with __GFP_ACCOUNT, including those that aren't actually charged to any
      cgroup, i.e. allocated from the root cgroup context.  To avoid overhead
      in case cgroups are not used, we only do that if memcg_kmem_enabled() is
      true.  The latter is set iff there are kmem-enabled memory cgroups
      (online or offline).  The root cgroup is not considered kmem-enabled.
      
      As a result, if a page is allocated with __GFP_ACCOUNT for the root
      cgroup when there are kmem-enabled memory cgroups and is freed after all
      kmem-enabled memory cgroups were removed, e.g.
      
        # no memory cgroups has been created yet, create one
        mkdir /sys/fs/cgroup/memory/test
        # run something allocating pages with __GFP_ACCOUNT, e.g.
        # a program using pipe
        dmesg | tail
        # remove the memory cgroup
        rmdir /sys/fs/cgroup/memory/test
      
      we'll get bad page state bug complaining about page->_mapcount != -1:
      
        BUG: Bad page state in process swapper/0  pfn:1fd945c
        page:ffffea007f651700 count:0 mapcount:-511 mapping:          (null) index:0x0
        flags: 0x1000000000000000()
      
      To avoid that, let's mark with PageKmemcg only those pages that are
      actually charged to and hence pin a non-root memory cgroup.
      
      Fixes: 4949148a ("mm: charge/uncharge kmemcg from generic page allocator paths")
      Reported-and-tested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarVladimir Davydov <vdavydov@virtuozzo.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c4159a75
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix tick_stop tracepoint symbols for user export · c87edb36
      Steven Rostedt (Red Hat) authored
      The symbols used in the tick_stop tracepoint were not being converted
      properly into integers in the trace_stop format file. Instead we had this:
      
      print fmt: "success=%d dependency=%s", REC->success,
          __print_symbolic(REC->dependency, { 0, "NONE" },
           { (1 << TICK_DEP_BIT_POSIX_TIMER), "POSIX_TIMER" },
           { (1 << TICK_DEP_BIT_PERF_EVENTS), "PERF_EVENTS" },
           { (1 << TICK_DEP_BIT_SCHED), "SCHED" },
           { (1 << TICK_DEP_BIT_CLOCK_UNSTABLE), "CLOCK_UNSTABLE" })
      
      User space tools have no idea how to parse "TICK_DEP_BIT_SCHED" or the other
      symbols used to do the bit shifting. The reason is that the conversion was
      done with using the TICK_DEP_MASK_* symbols which are just macros that
      convert to the BIT shift itself (with the exception of NONE, which was
      converted properly, because it doesn't use bits, and is defined as zero).
      
      The TICK_DEP_BIT_* needs to be denoted by TRACE_DEFINE_ENUM() in order to
      have this properly converted for user space tools to parse this event.
      
      Cc: stable@vger.kernel.org
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Fixes: e6e6cc22 ("nohz: Use enum code for tick stop failure tracing message")
      Reported-by: default avatarLuiz Capitulino <lcapitulino@redhat.com>
      Tested-by: default avatarLuiz Capitulino <lcapitulino@redhat.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      c87edb36
    • Boris Brezillon's avatar
      drm/cirrus: Fix NULL pointer dereference when registering the fbdev · 36e9d08b
      Boris Brezillon authored
      cirrus_modeset_init() is initializing/registering the emulated fbdev
      and, since commit c61b93fe ("drm/atomic: Fix remaining places where
      !funcs->best_encoder is valid"), DRM internals can access/test some of
      the fields in mode_config->funcs as part of the fbdev registration
      process.
      Make sure dev->mode_config.funcs is properly set to avoid dereferencing
      a NULL pointer.
      Reported-by: default avatarMike Marshall <hubcap@omnibond.com>
      Reported-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Fixes: c61b93fe ("drm/atomic: Fix remaining places where !funcs->best_encoder is valid")
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      36e9d08b
    • Emese Revfy's avatar
      gcc-plugins: Add support for plugin subdirectories · caefd8c9
      Emese Revfy authored
      This adds support for building more complex gcc plugins that live in a
      subdirectory instead of just in a single source file.
      Reported-by: default avatarPaX Team <pageexec@freemail.hu>
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      [kees: clarified commit message]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      caefd8c9
    • Emese Revfy's avatar
      gcc-plugins: Automate make rule generation · 7040c83b
      Emese Revfy authored
      There's no reason to repeat the same names in the Makefile when the .so
      files have already been listed. The .o list can be generated from them.
      Reported-by: default avatarPaX Team <pageexec@freemail.hu>
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      [kees: clarified commit message]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      7040c83b
    • Emese Revfy's avatar
      gcc-plugins: Add support for passing plugin arguments · 65d59ec8
      Emese Revfy authored
      The latent_entropy plugin needs to pass arguments, so this adds the
      support.
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      65d59ec8
    • Kees Cook's avatar
      gcc-plugins: abort builds cleanly when not supported · ed58c0e9
      Kees Cook authored
      When the compiler doesn't support gcc plugins (either due to missing
      headers or too old a version), report the problem and abort the build
      instead of emitting a warning and letting the build founder with arcane
      compiler errors.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      ed58c0e9
    • Emese Revfy's avatar
      kbuild: no gcc-plugins during cc-option tests · d26e9414
      Emese Revfy authored
      The gcc-plugins arguments should not be included when performing
      cc-option tests.
      
      Steps to reproduce:
      1) make mrproper
      2) make defconfig
      3) enable GCC_PLUGINS, GCC_PLUGIN_CYC_COMPLEXITY
      4) enable FUNCTION_TRACER (it will select other options as well)
      5) make && make modules
      
      Build errors:
      MODPOST 18 modules
      ERROR: "__fentry__" [net/netfilter/xt_nat.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/xt_mark.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/xt_addrtype.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/xt_LOG.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/nf_nat_sip.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/nf_nat_irc.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/nf_nat_ftp.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/nf_nat.ko] undefined!
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      [kees: renamed variable, clarified commit message]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      d26e9414
  4. 08 Aug, 2016 7 commits
    • Mario Kleiner's avatar
      drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS". · 210a021d
      Mario Kleiner authored
      According to E-EDID spec 1.3, table 3.9, a digital video sink with the
      "DFP 1.x compliant TMDS" bit set is "signal compatible with VESA DFP 1.x
      TMDS CRGB, 1 pixel / clock, up to 8 bits / color MSB aligned".
      
      For such displays, the DFP spec 1.0, section 3.10 "EDID support" says:
      
      "If the DFP monitor only supports EDID 1.X (1.1, 1.2, etc.)
       without extensions, the host will make the following assumptions:
      
       1. 24-bit MSB-aligned RGB TFT
       2. DE polarity is active high
       3. H and V syncs are active high
       4. Established CRT timings will be used
       5. Dithering will not be enabled on the host"
      
      So if we don't know the bit depth of the display from additional
      colorimetry info we should assume 8 bpc / 24 bpp by default.
      
      This patch adds info->bpc = 8 assignement for that case.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      210a021d
    • Mario Kleiner's avatar
      drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown" · 196f954e
      Mario Kleiner authored
      This reverts commit 013dd9e0
      ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")
      
      This commit introduced a regression into stable kernels,
      as it reduces output color depth to 6 bpc for any video
      sink connected to a Displayport connector if that sink
      doesn't report a specific color depth via EDID, or if
      our EDID parser doesn't actually recognize the proper
      bpc from EDID.
      
      Affected are active DisplayPort->VGA converters and
      active DisplayPort->DVI converters. Both should be
      able to handle 8 bpc, but are degraded to 6 bpc with
      this patch.
      
      The reverted commit was meant to fix
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
      
      A followup patch implements a fix for that specific bug,
      which is caused by a faulty EDID of the affected DP panel
      by adding a new EDID quirk for that panel.
      
      DP 18 bpp fallback handling and other improvements to
      DP sink bpc detection will be handled for future
      kernels in a separate series of patches.
      
      Please backport to stable.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Acked-by: default avatarJani Nikula <jani.nikula@intel.com>
      Cc: stable@vger.kernel.org
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      196f954e
    • Mario Kleiner's avatar
      drm/edid: Add 6 bpc quirk for display AEO model 0. · e10aec65
      Mario Kleiner authored
      Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331
      reports that the "AEO model 0" display is driven with 8 bpc
      without dithering by default, which looks bad because that
      panel is apparently a 6 bpc DP panel with faulty EDID.
      
      A fix for this was made by commit 013dd9e0
      ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").
      
      That commit triggers new regressions in precision for DP->DVI and
      DP->VGA displays. A patch is out to revert that commit, but it will
      revert video output for the AEO model 0 panel to 8 bpc without
      dithering.
      
      The EDID 1.3 of that panel, as decoded from the xrandr output
      attached to that bugzilla bug report, is somewhat faulty, and beyond
      other problems also sets the "DFP 1.x compliant TMDS" bit, which
      according to DFP spec means to drive the panel with 8 bpc and
      no dithering in absence of other colorimetry information.
      
      Try to make the original bug reporter happy despite the
      faulty EDID by adding a quirk to mark that panel as 6 bpc,
      so 6 bpc output with dithering creates a nice picture.
      
      Tested by injecting the edid from the fdo bug into a DP connector
      via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering
      is selected.
      
      This patch should be backported to stable.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: stable@vger.kernel.org
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      e10aec65
    • Linus Torvalds's avatar
      Merge tag 'lkdtm-v4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux · 81abf252
      Linus Torvalds authored
      Pull lkdtm update from Kees Cook:
       "Fix rebuild problem with LKDTM's rodata test"
      
      [ This, and the usercopy branch, both came in before the merge window
        closed, but ended up in my 'need to look more' queue and thus got
        merged only after rc1 was out ]
      
      * tag 'lkdtm-v4.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        lkdtm: Fix targets for objcopy usage
        lkdtm: fix false positive warning from -Wmaybe-uninitialized
      81abf252
    • Linus Torvalds's avatar
      Merge tag 'usercopy-v4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux · 1eccfa09
      Linus Torvalds authored
      Pull usercopy protection from Kees Cook:
       "Tbhis implements HARDENED_USERCOPY verification of copy_to_user and
        copy_from_user bounds checking for most architectures on SLAB and
        SLUB"
      
      * tag 'usercopy-v4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        mm: SLUB hardened usercopy support
        mm: SLAB hardened usercopy support
        s390/uaccess: Enable hardened usercopy
        sparc/uaccess: Enable hardened usercopy
        powerpc/uaccess: Enable hardened usercopy
        ia64/uaccess: Enable hardened usercopy
        arm64/uaccess: Enable hardened usercopy
        ARM: uaccess: Enable hardened usercopy
        x86/uaccess: Enable hardened usercopy
        mm: Hardened usercopy
        mm: Implement stack frame object validation
        mm: Add is_migrate_cma_page
      1eccfa09
    • Linus Torvalds's avatar
      unsafe_[get|put]_user: change interface to use a error target label · 1bd4403d
      Linus Torvalds authored
      When I initially added the unsafe_[get|put]_user() helpers in commit
      5b24a7a2 ("Add 'unsafe' user access functions for batched
      accesses"), I made the mistake of modeling the interface on our
      traditional __[get|put]_user() functions, which return zero on success,
      or -EFAULT on failure.
      
      That interface is fairly easy to use, but it's actually fairly nasty for
      good code generation, since it essentially forces the caller to check
      the error value for each access.
      
      In particular, since the error handling is already internally
      implemented with an exception handler, and we already use "asm goto" for
      various other things, we could fairly easily make the error cases just
      jump directly to an error label instead, and avoid the need for explicit
      checking after each operation.
      
      So switch the interface to pass in an error label, rather than checking
      the error value in the caller.  Best do it now before we start growing
      more users (the signal handling code in particular would be a good place
      to use the new interface).
      
      So rather than
      
      	if (unsafe_get_user(x, ptr))
      		... handle error ..
      
      the interface is now
      
      	unsafe_get_user(x, ptr, label);
      
      where an error during the user mode fetch will now just cause a jump to
      'label' in the caller.
      
      Right now the actual _implementation_ of this all still ends up being a
      "if (err) goto label", and does not take advantage of any exception
      label tricks, but for "unsafe_put_user()" in particular it should be
      fairly straightforward to convert to using the exception table model.
      
      Note that "unsafe_get_user()" is much harder to convert to a clever
      exception table model, because current versions of gcc do not allow the
      use of "asm goto" (for the exception) with output values (for the actual
      value to be fetched).  But that is hopefully not a limitation in the
      long term.
      
      [ Also note that it might be a good idea to switch unsafe_get_user() to
        actually _return_ the value it fetches from user space, but this
        commit only changes the error handling semantics ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1bd4403d
    • Andreas Ziegler's avatar
      printk: Remove unnecessary #ifdef CONFIG_PRINTK · 574673c2
      Andreas Ziegler authored
      In commit 874f9c7d ("printk: create pr_<level> functions"), new
      pr_level defines were added to printk.c.
      
      These new defines are guarded by an #ifdef CONFIG_PRINTK - however,
      there is already a surrounding #ifdef CONFIG_PRINTK starting a lot
      earlier in line 249 which means the newly introduced #ifdef is
      unnecessary.
      
      Let's remove it to avoid confusion.
      Signed-off-by: default avatarAndreas Ziegler <andreas.ziegler@fau.de>
      Cc: Joe Perches <joe@perches.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      574673c2