1. 02 Sep, 2019 3 commits
  2. 29 Aug, 2019 1 commit
    • Thomas Gleixner's avatar
      x86/mm/cpa: Prevent large page split when ftrace flips RW on kernel text · 7af01450
      Thomas Gleixner authored
      ftrace does not use text_poke() for enabling trace functionality. It uses
      its own mechanism and flips the whole kernel text to RW and back to RO.
      
      The CPA rework removed a loop based check of 4k pages which tried to
      preserve a large page by checking each 4k page whether the change would
      actually cover all pages in the large page.
      
      This resulted in endless loops for nothing as in testing it turned out that
      it actually never preserved anything. Of course testing missed to include
      ftrace, which is the one and only case which benefitted from the 4k loop.
      
      As a consequence enabling function tracing or ftrace based kprobes results
      in a full 4k split of the kernel text, which affects iTLB performance.
      
      The kernel RO protection is the only valid case where this can actually
      preserve large pages.
      
      All other static protections (RO data, data NX, PCI, BIOS) are truly
      static.  So a conflict with those protections which results in a split
      should only ever happen when a change of memory next to a protected region
      is attempted. But these conflicts are rightfully splitting the large page
      to preserve the protected regions. In fact a change to the protected
      regions itself is a bug and is warned about.
      
      Add an exception for the static protection check for kernel text RO when
      the to be changed region spawns a full large page which allows to preserve
      the large mappings. This also prevents the syslog to be spammed about CPA
      violations when ftrace is used.
      
      The exception needs to be removed once ftrace switched over to text_poke()
      which avoids the whole issue.
      
      Fixes: 585948f4 ("x86/mm/cpa: Avoid the 4k pages check completely")
      Reported-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarSong Liu <songliubraving@fb.com>
      Reviewed-by: default avatarSong Liu <songliubraving@fb.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1908282355340.1938@nanos.tec.linutronix.de
      7af01450
  3. 28 Aug, 2019 1 commit
    • Linus Torvalds's avatar
      x86/build: Add -Wnoaddress-of-packed-member to REALMODE_CFLAGS, to silence GCC9 build warning · 42e0e954
      Linus Torvalds authored
      One of the very few warnings I have in the current build comes from
      arch/x86/boot/edd.c, where I get the following with a gcc9 build:
      
         arch/x86/boot/edd.c: In function ‘query_edd’:
         arch/x86/boot/edd.c:148:11: warning: taking address of packed member of ‘struct boot_params’ may result in an unaligned pointer value [-Waddress-of-packed-member]
           148 |  mbrptr = boot_params.edd_mbr_sig_buffer;
               |           ^~~~~~~~~~~
      
      This warning triggers because we throw away all the CFLAGS and then make
      a new set for REALMODE_CFLAGS, so the -Wno-address-of-packed-member we
      added in the following commit is not present:
      
        6f303d60 ("gcc-9: silence 'address-of-packed-member' warning")
      
      The simplest solution for now is to adjust the warning for this version
      of CFLAGS as well, but it would definitely make sense to examine whether
      REALMODE_CFLAGS could be derived from CFLAGS, so that it picks up changes
      in the compiler flags environment automatically.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: default avatarBorislav Petkov <bp@alien8.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      42e0e954
  4. 27 Aug, 2019 1 commit
  5. 26 Aug, 2019 4 commits
    • Bandan Das's avatar
      x86/apic: Include the LDR when clearing out APIC registers · 558682b5
      Bandan Das authored
      Although APIC initialization will typically clear out the LDR before
      setting it, the APIC cleanup code should reset the LDR.
      
      This was discovered with a 32-bit KVM guest jumping into a kdump
      kernel. The stale bits in the LDR triggered a bug in the KVM APIC
      implementation which caused the destination mapping for VCPUs to be
      corrupted.
      
      Note that this isn't intended to paper over the KVM APIC bug. The kernel
      has to clear the LDR when resetting the APIC registers except when X2APIC
      is enabled.
      
      This lacks a Fixes tag because missing to clear LDR goes way back into pre
      git history.
      
      [ tglx: Made x2apic_enabled a function call as required ]
      Signed-off-by: default avatarBandan Das <bsd@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190826101513.5080-3-bsd@redhat.com
      558682b5
    • Bandan Das's avatar
      x86/apic: Do not initialize LDR and DFR for bigsmp · bae3a8d3
      Bandan Das authored
      Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
      bigsmp APIC implementation uses physical destination mode, but it
      nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
      multiple bit being set.
      
      This does not cause a functional problem because LDR and DFR are ignored
      when physical destination mode is active, but it triggered a problem on a
      32-bit KVM guest which jumps into a kdump kernel.
      
      The multiple bits set unearthed a bug in the KVM APIC implementation. The
      code which creates the logical destination map for VCPUs ignores the
      disabled state of the APIC and ends up overwriting an existing valid entry
      and as a result, APIC calibration hangs in the guest during kdump
      initialization.
      
      Remove the bogus LDR/DFR initialization.
      
      This is not intended to work around the KVM APIC bug. The LDR/DFR
      ininitalization is wrong on its own.
      
      The issue goes back into the pre git history. The fixes tag is the commit
      in the bitkeeper import which introduced bigsmp support in 2003.
      
        git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
      
      Fixes: db7b9e9f ("[PATCH] Clustered APIC setup for >8 CPU systems")
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarBandan Das <bsd@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190826101513.5080-2-bsd@redhat.com
      
      bae3a8d3
    • Sebastian Mayr's avatar
      uprobes/x86: Fix detection of 32-bit user mode · 9212ec7d
      Sebastian Mayr authored
      32-bit processes running on a 64-bit kernel are not always detected
      correctly, causing the process to crash when uretprobes are installed.
      
      The reason for the crash is that in_ia32_syscall() is used to determine the
      process's mode, which only works correctly when called from a syscall.
      
      In the case of uretprobes, however, the function is called from a exception
      and always returns 'false' on a 64-bit kernel. In consequence this leads to
      corruption of the process's return address.
      
      Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
      is correct in any situation.
      
      [ tglx: Add a comment and the following historical info ]
      
      This should have been detected by the rename which happened in commit
      
        abfb9498 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")
      
      which states in the changelog:
      
          The is_ia32_task()/is_x32_task() function names are a big misnomer: they
          suggests that the compat-ness of a system call is a task property, which
          is not true, the compatness of a system call purely depends on how it
          was invoked through the system call layer.
          .....
      
      and then it went and blindly renamed every call site.
      
      Sadly enough this was already mentioned here:
      
         8faaed1b ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
      arch_uretprobe_hijack_return_addr()")
      
      where the changelog says:
      
          TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
          not necessarily mean 32bit. Fortunately syscall-like insns can't be
          probed so it actually works, but it would be better to rename and
          use is_ia32_frame().
      
      and goes all the way back to:
      
          0326f5a9 ("uprobes/core: Handle breakpoint and singlestep exceptions")
      
      Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
      process on a 64bit kernel....
      
      Fixes: 0326f5a9 ("uprobes/core: Handle breakpoint and singlestep exceptions")
      Signed-off-by: default avatarSebastian Mayr <me@sam.st>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
      9212ec7d
    • Thomas Gleixner's avatar
      x86/apic: Fix arch_dynirq_lower_bound() bug for DT enabled machines · 3e5bedc2
      Thomas Gleixner authored
      Rahul Tanwar reported the following bug on DT systems:
      
      > 'ioapic_dynirq_base' contains the virtual IRQ base number. Presently, it is
      > updated to the end of hardware IRQ numbers but this is done only when IOAPIC
      > configuration type is IOAPIC_DOMAIN_LEGACY or IOAPIC_DOMAIN_STRICT. There is
      > a third type IOAPIC_DOMAIN_DYNAMIC which applies when IOAPIC configuration
      > comes from devicetree.
      >
      > See dtb_add_ioapic() in arch/x86/kernel/devicetree.c
      >
      > In case of IOAPIC_DOMAIN_DYNAMIC (DT/OF based system), 'ioapic_dynirq_base'
      > remains to zero initialized value. This means that for OF based systems,
      > virtual IRQ base will get set to zero.
      
      Such systems will very likely not even boot.
      
      For DT enabled machines ioapic_dynirq_base is irrelevant and not
      updated, so simply map the IRQ base 1:1 instead.
      Reported-by: default avatarRahul Tanwar <rahul.tanwar@linux.intel.com>
      Tested-by: default avatarRahul Tanwar <rahul.tanwar@linux.intel.com>
      Tested-by: default avatarAndy Shevchenko <andriy.shevchenko@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: alan@linux.intel.com
      Cc: bp@alien8.de
      Cc: cheol.yong.kim@intel.com
      Cc: qi-ming.wu@intel.com
      Cc: rahul.tanwar@intel.com
      Cc: rppt@linux.ibm.com
      Cc: tony.luck@intel.com
      Link: http://lkml.kernel.org/r/20190821081330.1187-1-rahul.tanwar@linux.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3e5bedc2
  6. 23 Aug, 2019 1 commit
    • Sean Christopherson's avatar
      x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386 · b63f20a7
      Sean Christopherson authored
      Use 'lea' instead of 'add' when adjusting %rsp in CALL_NOSPEC so as to
      avoid clobbering flags.
      
      KVM's emulator makes indirect calls into a jump table of sorts, where
      the destination of the CALL_NOSPEC is a small blob of code that performs
      fast emulation by executing the target instruction with fixed operands.
      
        adcb_al_dl:
           0x000339f8 <+0>:   adc    %dl,%al
           0x000339fa <+2>:   ret
      
      A major motiviation for doing fast emulation is to leverage the CPU to
      handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is
      both an input and output to the target of CALL_NOSPEC.  Clobbering flags
      results in all sorts of incorrect emulation, e.g. Jcc instructions often
      take the wrong path.  Sans the nops...
      
        asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"
           0x0003595a <+58>:  mov    0xc0(%ebx),%eax
           0x00035960 <+64>:  mov    0x60(%ebx),%edx
           0x00035963 <+67>:  mov    0x90(%ebx),%ecx
           0x00035969 <+73>:  push   %edi
           0x0003596a <+74>:  popf
           0x0003596b <+75>:  call   *%esi
           0x000359a0 <+128>: pushf
           0x000359a1 <+129>: pop    %edi
           0x000359a2 <+130>: mov    %eax,0xc0(%ebx)
           0x000359b1 <+145>: mov    %edx,0x60(%ebx)
      
        ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK);
           0x000359a8 <+136>: mov    -0x10(%ebp),%eax
           0x000359ab <+139>: and    $0x8d5,%edi
           0x000359b4 <+148>: and    $0xfffff72a,%eax
           0x000359b9 <+153>: or     %eax,%edi
           0x000359bd <+157>: mov    %edi,0x4(%ebx)
      
      For the most part this has gone unnoticed as emulation of guest code
      that can trigger fast emulation is effectively limited to MMIO when
      running on modern hardware, and MMIO is rarely, if ever, accessed by
      instructions that affect or consume flags.
      
      Breakage is almost instantaneous when running with unrestricted guest
      disabled, in which case KVM must emulate all instructions when the guest
      has invalid state, e.g. when the guest is in Big Real Mode during early
      BIOS.
      
      Fixes: 776b043848fd2 ("x86/retpoline: Add initial retpoline support")
      Fixes: 1a29b5b7 ("KVM: x86: Make indirect calls in emulator speculation safe")
      Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190822211122.27579-1-sean.j.christopherson@intel.com
      b63f20a7
  7. 21 Aug, 2019 1 commit
  8. 19 Aug, 2019 3 commits
    • Tom Lendacky's avatar
      x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h · c49a0a80
      Tom Lendacky authored
      There have been reports of RDRAND issues after resuming from suspend on
      some AMD family 15h and family 16h systems. This issue stems from a BIOS
      not performing the proper steps during resume to ensure RDRAND continues
      to function properly.
      
      RDRAND support is indicated by CPUID Fn00000001_ECX[30]. This bit can be
      reset by clearing MSR C001_1004[62]. Any software that checks for RDRAND
      support using CPUID, including the kernel, will believe that RDRAND is
      not supported.
      
      Update the CPU initialization to clear the RDRAND CPUID bit for any family
      15h and 16h processor that supports RDRAND. If it is known that the family
      15h or family 16h system does not have an RDRAND resume issue or that the
      system will not be placed in suspend, the "rdrand=force" kernel parameter
      can be used to stop the clearing of the RDRAND CPUID bit.
      
      Additionally, update the suspend and resume path to save and restore the
      MSR C001_1004 value to ensure that the RDRAND CPUID setting remains in
      place after resuming from suspend.
      
      Note, that clearing the RDRAND CPUID bit does not prevent a processor
      that normally supports the RDRAND instruction from executing it. So any
      code that determined the support based on family and model won't #UD.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Andrew Cooper <andrew.cooper3@citrix.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Chen Yu <yu.c.chen@intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
      Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
      Cc: Nathan Chancellor <natechancellor@gmail.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: <stable@vger.kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "x86@kernel.org" <x86@kernel.org>
      Link: https://lkml.kernel.org/r/7543af91666f491547bd86cebb1e17c66824ab9f.1566229943.git.thomas.lendacky@amd.com
      c49a0a80
    • Kirill A. Shutemov's avatar
      x86/boot/compressed/64: Fix boot on machines with broken E820 table · 0a46fff2
      Kirill A. Shutemov authored
      BIOS on Samsung 500C Chromebook reports very rudimentary E820 table that
      consists of 2 entries:
      
        BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] usable
        BIOS-e820: [mem 0x00000000fffff000-0x00000000ffffffff] reserved
      
      It breaks logic in find_trampoline_placement(): bios_start lands on the
      end of the first 4k page and trampoline start gets placed below 0.
      
      Detect underflow and don't touch bios_start for such cases. It makes
      kernel ignore E820 table on machines that doesn't have two usable pages
      below BIOS_START_MAX.
      
      Fixes: 1b3a6264 ("x86/boot/compressed/64: Validate trampoline placement against E820")
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=203463
      Link: https://lkml.kernel.org/r/20190813131654.24378-1-kirill.shutemov@linux.intel.com
      0a46fff2
    • Thomas Gleixner's avatar
      x86/apic: Handle missing global clockevent gracefully · f897e60a
      Thomas Gleixner authored
      Some newer machines do not advertise legacy timers. The kernel can handle
      that situation if the TSC and the CPU frequency are enumerated by CPUID or
      MSRs and the CPU supports TSC deadline timer. If the CPU does not support
      TSC deadline timer the local APIC timer frequency has to be known as well.
      
      Some Ryzens machines do not advertize legacy timers, but there is no
      reliable way to determine the bus frequency which feeds the local APIC
      timer when the machine allows overclocking of that frequency.
      
      As there is no legacy timer the local APIC timer calibration crashes due to
      a NULL pointer dereference when accessing the not installed global clock
      event device.
      
      Switch the calibration loop to a non interrupt based one, which polls
      either TSC (if frequency is known) or jiffies. The latter requires a global
      clockevent. As the machines which do not have a global clockevent installed
      have a known TSC frequency this is a non issue. For older machines where
      TSC frequency is not known, there is no known case where the legacy timers
      do not exist as that would have been reported long ago.
      Reported-by: default avatarDaniel Drake <drake@endlessm.com>
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarDaniel Drake <drake@endlessm.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1908091443030.21433@nanos.tec.linutronix.de
      Link: http://bugzilla.opensuse.org/show_bug.cgi?id=1142926#c12
      f897e60a
  9. 17 Aug, 2019 1 commit
  10. 16 Aug, 2019 1 commit
  11. 15 Aug, 2019 1 commit
  12. 12 Aug, 2019 3 commits
    • Thomas Gleixner's avatar
      x86/fpu/math-emu: Address fallthrough warnings · 91be2587
      Thomas Gleixner authored
      /home/tglx/work/kernel/linus/linux/arch/x86/math-emu/errors.c: In function ‘FPU_printall’:
      /home/tglx/work/kernel/linus/linux/arch/x86/math-emu/errors.c:187:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
          tagi = FPU_Special(r);
          ~~~~~^~~~~~~~~~~~~~~~
      /home/tglx/work/kernel/linus/linux/arch/x86/math-emu/errors.c:188:3: note: here
         case TAG_Valid:
         ^~~~
      /home/tglx/work/kernel/linus/linux/arch/x86/math-emu/fpu_trig.c: In function ‘fyl2xp1’:
      /home/tglx/work/kernel/linus/linux/arch/x86/math-emu/fpu_trig.c:1353:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
          if (denormal_operand() < 0)
             ^
      /home/tglx/work/kernel/linus/linux/arch/x86/math-emu/fpu_trig.c:1356:3: note: here
         case TAG_Zero:
      
      Remove the pointless 'break;' after 'continue;' while at it.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      91be2587
    • Borislav Petkov's avatar
      x86/apic/32: Fix yet another implicit fallthrough warning · 5785675d
      Borislav Petkov authored
      Fix
      
        arch/x86/kernel/apic/probe_32.c: In function ‘default_setup_apic_routing’:
        arch/x86/kernel/apic/probe_32.c:146:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
            if (!APIC_XAPIC(version)) {
               ^
        arch/x86/kernel/apic/probe_32.c:151:3: note: here
         case X86_VENDOR_HYGON:
         ^~~~
      
      for 32-bit builds.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/20190811154036.29805-1-bp@alien8.de
      5785675d
    • Fenghua Yu's avatar
      x86/umwait: Fix error handling in umwait_init() · e7409258
      Fenghua Yu authored
      Currently, failure of cpuhp_setup_state() is ignored and the syscore ops
      and the control interfaces can still be added even after the failure. But,
      this error handling will cause a few issues:
      
      1. The CPUs may have different values in the IA32_UMWAIT_CONTROL
         MSR because there is no way to roll back the control MSR on
         the CPUs which already set the MSR before the failure.
      
      2. If the sysfs interface is added successfully, there will be a mismatch
         between the global control value and the control MSR:
         - The interface shows the default global control value. But,
           the control MSR is not set to the value because the CPU online
           function, which is supposed to set the MSR to the value,
           is not installed.
         - If the sysadmin changes the global control value through
           the interface, the control MSR on all current online CPUs is
           set to the new value. But, the control MSR on newly onlined CPUs
           after the value change will not be set to the new value due to
           lack of the CPU online function.
      
      3. On resume from suspend/hibernation, the boot CPU restores the control
         MSR to the global control value through the syscore ops. But, the
         control MSR on all APs is not set due to lake of the CPU online
         function.
      
      To solve the issues and enforce consistent behavior on the failure
      of the CPU hotplug setup, make the following changes:
      
      1. Cache the original control MSR value which is configured by
         hardware or BIOS before kernel boot. This value is likely to
         be 0. But it could be a different number as well. Cache the
         control MSR only once before the MSR is changed.
      2. Add the CPU offline function so that the MSR is restored to the
         original control value on all CPUs on the failure.
      3. On the failure, exit from cpumait_init() so that the syscore ops
         and the control interfaces are not added.
      Reported-by: default avatarValdis Kletnieks <valdis.kletnieks@vt.edu>
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarFenghua Yu <fenghua.yu@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/1565401237-60936-1-git-send-email-fenghua.yu@intel.com
      e7409258
  13. 11 Aug, 2019 3 commits
  14. 10 Aug, 2019 16 commits
    • Linus Torvalds's avatar
      Merge tag 'riscv/for-v5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux · 296d05cb
      Linus Torvalds authored
      Pull RISC-V updates from Paul Walmsley:
       "A few minor RISC-V updates for v5.3-rc4:
      
         - Remove __udivdi3() from the 32-bit Linux port, converting the only
           upstream user to use do_div(), per Linux policy
      
         - Convert the RISC-V standard clocksource away from per-cpu data
           structures, since only one is used by Linux, even on a multi-CPU
           system
      
         - A set of DT binding updates that remove an obsolete text binding in
           favor of a YAML binding, fix a bogus compatible string in the
           schema (thus fixing a "make dtbs_check" warning), and clarifies the
           future values expected in one of the RISC-V CPU properties"
      
      * tag 'riscv/for-v5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
        dt-bindings: riscv: fix the schema compatible string for the HiFive Unleashed board
        dt-bindings: riscv: remove obsolete cpus.txt
        RISC-V: Remove udivdi3
        riscv: delay: use do_div() instead of __udivdi3()
        dt-bindings: Update the riscv,isa string description
        RISC-V: Remove per cpu clocksource
      296d05cb
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 6d8f809c
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
       "A few fixes for x86:
      
         - Don't reset the carefully adjusted build flags for the purgatory
           and remove the unwanted flags instead. The 'reset all' approach led
           to build fails under certain circumstances.
      
         - Unbreak CLANG build of the purgatory by avoiding the builtin
           memcpy/memset implementations.
      
         - Address missing prototype warnings by including the proper header
      
         - Fix yet more fall-through issues"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/lib/cpu: Address missing prototypes warning
        x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS
        x86/purgatory: Do not use __builtin_memcpy and __builtin_memset
        x86: mtrr: cyrix: Mark expected switch fall-through
        x86/ptrace: Mark expected switch fall-through
      6d8f809c
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · d2359a51
      Linus Torvalds authored
      Pull perf tooling fixes from Thomas Gleixner:
       "Perf tooling fixes all over the place:
      
         - Fix the selection of the main thread COMM in db-export
      
         - Fix the disassemmbly display for BPF in annotate
      
         - Fix cpumap mask setup in perf ftrace when only one CPU is present
      
         - Add the missing 'cpu_clk_unhalted.core' event
      
         - Fix CPU 0 bindings in NUMA benchmarks
      
         - Fix the module size calculations for s390
      
         - Handle the gap between kernel end and module start on s390
           correctly
      
         - Build and typo fixes"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf pmu-events: Fix missing "cpu_clk_unhalted.core" event
        perf annotate: Fix s390 gap between kernel end and module start
        perf record: Fix module size on s390
        perf tools: Fix include paths in ui directory
        perf tools: Fix a typo in a variable name in the Documentation Makefile
        perf cpumap: Fix writing to illegal memory in handling cpumap mask
        perf ftrace: Fix failure to set cpumask when only one cpu is present
        perf db-export: Fix thread__exec_comm()
        perf annotate: Fix printing of unaugmented disassembled instructions from BPF
        perf bench numa: Fix cpu0 binding
      d2359a51
    • Linus Torvalds's avatar
      Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · dcbb4a15
      Linus Torvalds authored
      Pull scheduler fixes from Thomas Gleixner:
       "Three fixlets for the scheduler:
      
         - Avoid double bandwidth accounting in the push & pull code
      
         - Use a sane FIFO priority for the Pressure Stall Information (PSI)
           thread.
      
         - Avoid permission checks when setting the scheduler params for the
           PSI thread"
      
      * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/psi: Do not require setsched permission from the trigger creator
        sched/psi: Reduce psimon FIFO priority
        sched/deadline: Fix double accounting of rq/running bw in push & pull
      dcbb4a15
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · ed254bb5
      Linus Torvalds authored
      Pull irq fix from Thomas Gleixner:
       "A small fix for the affinity spreading code.
      
        It failed to handle situations where a single vector was requested
        either due to only one CPU being available or vector exhaustion
        causing only a single interrupt to be granted.
      
        The fix is to simply remove the requirement in the affinity spreading
        code for more than one interrupt being available"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        genirq/affinity: Create affinity mask for single vector
      ed254bb5
    • Linus Torvalds's avatar
      Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 6054f4ec
      Linus Torvalds authored
      Pull objtool warning fix from Thomas Gleixner:
       "The recent objtool fixes/enhancements unearthed a unbalanced CLAC in
        the i915 driver.
      
        Chris asked me to pick the fix up and route it through"
      
      * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        drm/i915: Remove redundant user_access_end() from __copy_from_user() error path
      6054f4ec
    • Linus Torvalds's avatar
      Merge tag 'gfs2-v5.3-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 · 829890d2
      Linus Torvalds authored
      Pull gfs2 fix from Andreas Gruenbacher:
       "Fix incorrect lseek / fiemap results"
      
      * tag 'gfs2-v5.3-rc3.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2:
        gfs2: gfs2_walk_metadata fix
      829890d2
    • Joe Perches's avatar
      Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang · bfd77145
      Joe Perches authored
      A compilation -Wimplicit-fallthrough warning was enabled by commit
      a035d552 ("Makefile: Globally enable fall-through warning")
      
      Even though clang 10.0.0 does not currently support this warning without
      a patch, clang currently does not support a value for this option.
      
        Link: https://bugs.llvm.org/show_bug.cgi?id=39382
      
      The gcc default for this warning is 3 so removing the =3 has no effect
      for gcc and enables the warning for patched versions of clang.
      
      Also remove the =3 from an existing use in a parisc Makefile:
      arch/parisc/math-emu/Makefile
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Reviewed-and-tested-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bfd77145
    • Linus Torvalds's avatar
      Merge tag 'char-misc-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc · 5aa91007
      Linus Torvalds authored
      Pull char/misc driver fixes Greg KH:
       "Here are some small char/misc driver fixes for 5.3-rc4.
      
        Two of these are for the habanalabs driver for issues found when
        running on a big-endian system (are they still alive?) The others are
        tiny fixes reported by people, and a MAINTAINERS update about the
        location of the fpga development tree.
      
        All of these have been in linux-next for a while with no reported
        issues"
      
      * tag 'char-misc-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
        coresight: Fix DEBUG_LOCKS_WARN_ON for uninitialized attribute
        MAINTAINERS: Move linux-fpga tree to new location
        nvmem: Use the same permissions for eeprom as for nvmem
        habanalabs: fix host memory polling in BE architecture
        habanalabs: fix F/W download in BE architecture
      5aa91007
    • Linus Torvalds's avatar
      Merge tag 'driver-core-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core · 36e630ed
      Linus Torvalds authored
      Pull driver core fixes from Greg KH:
       "Here are two small fixes for some driver core issues that have been
        reported. There is also a kernfs "fix" here, which was then reverted
        because it was found to cause problems in linux-next.
      
        The driver core fixes both resolve reported issues, one with gpioint
        stuff that showed up in 5.3-rc1, and the other finally (and hopefully)
        resolves a very long standing race when removing glue directories.
        It's nice to get that issue finally resolved and the developers
        involved should be applauded for the persistence it took to get this
        patch finally accepted.
      
        All of these have been in linux-next for a while with no reported
        issues. Well, the one reported issue, hence the revert :)"
      
      * tag 'driver-core-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
        Revert "kernfs: fix memleak in kernel_ops_readdir()"
        kernfs: fix memleak in kernel_ops_readdir()
        driver core: Fix use-after-free and double free on glue directory
        driver core: platform: return -ENXIO for missing GpioInt
      36e630ed
    • Linus Torvalds's avatar
      Merge tag 'tty-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · c13f8670
      Linus Torvalds authored
      Pull tty fix from Greg KH:
       "Here is a single tty kgdb fix for 5.3-rc4.
      
        It fixes an annoying log message that has caused kdb to become
        useless. It's another fallout from commit ddde3c18 ("vt: More
        locking checks") which tries to enforce locking checks more strictly
        in the tty layer, unfortunatly when kdb is stopped, there's no need
        for locks :)
      
        This patch has been linux-next for a while with no reported issues"
      
      * tag 'tty-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        kgdboc: disable the console lock when in kgdb
      c13f8670
    • Linus Torvalds's avatar
      Merge tag 'staging-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging · 15fa98e4
      Linus Torvalds authored
      Pull staging / IIO driver fixes from Greg KH:
       "Here are some small staging and IIO driver fixes for 5.3-rc4.
      
        Nothing major, just resolutions for a number of small reported issues,
        full details in the shortlog.
      
        All have been in linux-next for a while with no reported issues"
      
      * tag 'staging-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
        iio: adc: gyroadc: fix uninitialized return code
        docs: generic-counter.rst: fix broken references for ABI file
        staging: android: ion: Bail out upon SIGKILL when allocating memory.
        Staging: fbtft: Fix GPIO handling
        staging: unisys: visornic: Update the description of 'poll_for_irq()'
        staging: wilc1000: flush the workqueue before deinit the host
        staging: gasket: apex: fix copy-paste typo
        Staging: fbtft: Fix reset assertion when using gpio descriptor
        Staging: fbtft: Fix probing of gpio descriptor
        iio: imu: mpu6050: add missing available scan masks
        iio: cros_ec_accel_legacy: Fix incorrect channel setting
        IIO: Ingenic JZ47xx: Set clock divider on probe
        iio: adc: max9611: Fix misuse of GENMASK macro
      15fa98e4
    • Linus Torvalds's avatar
      Merge tag 'usb-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · 1041f509
      Linus Torvalds authored
      Pull USB fixes from Greg KH:
       "Here are some small USB fixes for 5.3-rc4.
      
        The "biggest" one here is moving code from one file to another in
        order to fix a long-standing race condition with the creation of sysfs
        files for USB devices. Turns out that there are now userspace tools
        out there that are hitting this long-known bug, so it's time to fix
        them. Thankfully the tool-maker in this case fixed the issue :)
      
        The other patches in here are all fixes for reported issues. Now that
        syzbot knows how to fuzz USB drivers better, and is starting to now
        fuzz the userspace facing side of them at the same time, there will be
        more and more small fixes like these coming, which is a good thing.
      
        All of these have been in linux-next with no reported issues"
      
      * tag 'usb-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
        usb: setup authorized_default attributes using usb_bus_notify
        usb: iowarrior: fix deadlock on disconnect
        Revert "USB: rio500: simplify locking"
        usb: usbfs: fix double-free of usb memory upon submiturb error
        usb: yurex: Fix use-after-free in yurex_delete
        usb: typec: tcpm: Ignore unsupported/unknown alternate mode requests
        xhci: Fix NULL pointer dereference at endpoint zero reset.
        usb: host: xhci-rcar: Fix timeout in xhci_suspend()
        usb: typec: ucsi: ccg: Fix uninitilized symbol error
        usb: typec: tcpm: remove tcpm dir if no children
        usb: typec: tcpm: free log buf memory when remove debug file
        usb: typec: tcpm: Add NULL check before dereferencing config
      1041f509
    • Linus Torvalds's avatar
      Merge tag 'pinctrl-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl · 97946f59
      Linus Torvalds authored
      Pull pin control fixes from Linus Walleij:
      
       - Delay acquisition of regmaps in the Aspeed G5 driver.
      
       - Make a symbol static to reduce compiler noise.
      
      * tag 'pinctrl-v5.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: aspeed: Make aspeed_pinmux_ips static
        pinctrl: aspeed-g5: Delay acquisition of regmaps
      97946f59
    • Linus Torvalds's avatar
      Merge tag 'powerpc-5.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · 23df57af
      Linus Torvalds authored
      Pull powerpc fix from Michael Ellerman:
       "Just one fix, a revert of a commit that was meant to be a minor
        improvement to some inline asm, but ended up having no real benefit
        with GCC and broke booting 32-bit machines when using Clang.
      
        Thanks to: Arnd Bergmann, Christophe Leroy, Nathan Chancellor, Nick
        Desaulniers, Segher Boessenkool"
      
      * tag 'powerpc-5.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        Revert "powerpc: slightly improve cache helpers"
      23df57af
    • Linus Torvalds's avatar
      Merge tag 'Wimplicit-fallthrough-5.3-rc4' of... · bf1881cf
      Linus Torvalds authored
      Merge tag 'Wimplicit-fallthrough-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux
      
      Pull fall-through fixes from Gustavo A. R. Silva:
       "Mark more switch cases where we are expecting to fall through, fixing
        fall-through warnings in arm, sparc64, mips, i386 and s390"
      
      * tag 'Wimplicit-fallthrough-5.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux:
        ARM: ep93xx: Mark expected switch fall-through
        scsi: fas216: Mark expected switch fall-throughs
        pcmcia: db1xxx_ss: Mark expected switch fall-throughs
        video: fbdev: omapfb_main: Mark expected switch fall-throughs
        watchdog: riowd: Mark expected switch fall-through
        s390/net: Mark expected switch fall-throughs
        crypto: ux500/crypt: Mark expected switch fall-throughs
        watchdog: wdt977: Mark expected switch fall-through
        watchdog: scx200_wdt: Mark expected switch fall-through
        watchdog: Mark expected switch fall-throughs
        ARM: signal: Mark expected switch fall-through
        mfd: omap-usb-host: Mark expected switch fall-throughs
        mfd: db8500-prcmu: Mark expected switch fall-throughs
        ARM: OMAP: dma: Mark expected switch fall-throughs
        ARM: alignment: Mark expected switch fall-throughs
        ARM: tegra: Mark expected switch fall-through
        ARM/hw_breakpoint: Mark expected switch fall-throughs
      bf1881cf