1. 30 9月, 2017 2 次提交
  2. 29 9月, 2017 1 次提交
    • J
      x86/asm: Fix inline asm call constraints for GCC 4.4 · 520a13c5
      Josh Poimboeuf 提交于
      The kernel test bot (run by Xiaolong Ye) reported that the following commit:
      
        f5caf621 ("x86/asm: Fix inline asm call constraints for Clang")
      
      is causing double faults in a kernel compiled with GCC 4.4.
      
      Linus subsequently diagnosed the crash pattern and the buggy commit and found that
      the issue is with this code:
      
        register unsigned int __asm_call_sp asm("esp");
        #define ASM_CALL_CONSTRAINT "+r" (__asm_call_sp)
      
      Even on a 64-bit kernel, it's using ESP instead of RSP.  That causes GCC
      to produce the following bogus code:
      
        ffffffff8147461d:       89 e0                   mov    %esp,%eax
        ffffffff8147461f:       4c 89 f7                mov    %r14,%rdi
        ffffffff81474622:       4c 89 fe                mov    %r15,%rsi
        ffffffff81474625:       ba 20 00 00 00          mov    $0x20,%edx
        ffffffff8147462a:       89 c4                   mov    %eax,%esp
        ffffffff8147462c:       e8 bf 52 05 00          callq  ffffffff814c98f0 <copy_user_generic_unrolled>
      
      Despite the absurdity of it backing up and restoring the stack pointer
      for no reason, the bug is actually the fact that it's only backing up
      and restoring the lower 32 bits of the stack pointer.  The upper 32 bits
      are getting cleared out, corrupting the stack pointer.
      
      So change the '__asm_call_sp' register variable to be associated with
      the actual full-size stack pointer.
      
      This also requires changing the __ASM_SEL() macro to be based on the
      actual compiled arch size, rather than the CONFIG value, because
      CONFIG_X86_64 compiles some files with '-m32' (e.g., realmode and vdso).
      Otherwise Clang fails to build the kernel because it complains about the
      use of a 64-bit register (RSP) in a 32-bit file.
      Reported-and-Bisected-and-Tested-by: Nkernel test robot <xiaolong.ye@intel.com>
      Diagnosed-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Dmitriy Vyukov <dvyukov@google.com>
      Cc: LKP <lkp@01.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthias Kaehlcke <mka@chromium.org>
      Cc: Miguel Bernal Marin <miguel.bernal.marin@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: f5caf621 ("x86/asm: Fix inline asm call constraints for Clang")
      Link: http://lkml.kernel.org/r/20170928215826.6sdpmwtkiydiytim@trebleSigned-off-by: NIngo Molnar <mingo@kernel.org>
      520a13c5
  3. 25 9月, 2017 7 次提交
  4. 23 9月, 2017 11 次提交
  5. 21 9月, 2017 6 次提交
    • M
      MIPS: PCI: fix pcibios_map_irq section mismatch · 8eba3651
      Manuel Lauss 提交于
      Drop  the __init from pcibios_map_irq() to make this section mis-
      match go away:
      
      WARNING: vmlinux.o(.text+0x56acd4): Section mismatch in reference from the function pcibios_scanbus() to the function .init.text:pcibios_map_irq()
      The function pcibios_scanbus() references
      the function __init pcibios_map_irq().
      This is often because pcibios_scanbus lacks a __init
      annotation or the annotation of pcibios_map_irq is wrong.
      
      Run-Tested only on Alchemy.
      Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17267/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      8eba3651
    • J
      MIPS: Fix input modify in __write_64bit_c0_split() · c22c8043
      James Hogan 提交于
      The inline asm in __write_64bit_c0_split() modifies the 64-bit input
      operand by shifting the high register left by 32, and constructing the
      full 64-bit value in the low register (even on a 32-bit kernel), so if
      that value is used again it could cause breakage as GCC would assume the
      registers haven't changed when they have.
      
      To quote the GCC extended asm documentation:
      > Warning: Do not modify the contents of input-only operands (except for
      > inputs tied to outputs). The compiler assumes that on exit from the
      > asm statement these operands contain the same values as they had
      > before executing the statement.
      
      Avoid modifying the input by using a temporary variable as an output
      which is modified instead of the input and not otherwise used. The asm
      is always __volatile__ so GCC shouldn't optimise it out. The low
      register of the temporary output is written before the high register of
      the input is read, so we have two constraint alternatives, one where
      both use the same registers (for when the input value isn't subsequently
      used), and one with an early clobber on the output in case the low
      output uses the same register as the high input. This allows the
      resulting assembly to remain mostly unchanged.
      
      A diff of a MIPS32r6 kernel reveals only three differences, two in
      relation to write_c0_r10k_diag() in cpu_probe() (register allocation
      rearranged slightly but otherwise identical), and one in relation to
      write_c0_cvmmemctl2() in kvm_vz_local_flush_guesttlb_all(), but the
      octeon CPU is only supported on 64-bit kernels where
      __write_64bit_c0_split() isn't used so that shouldn't matter in
      practice. So there currently doesn't appear to be anything broken by
      this bug.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/17315/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c22c8043
    • A
      MIPS: MSP71xx: Include asm/setup.h · 9bbe7dc0
      Arnd Bergmann 提交于
      msp71xx_defconfig can not be built at the in v4.14-rc1
      
      arch/mips/pmcs-msp71xx/msp_smp.c:72:2: error: implicit declaration of function 'set_vi_handler' [-Werror=implicit-function-declaration]
      
      I don't know what caused the regression, but including the right
      header is the obvious fix.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/17309/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9bbe7dc0
    • T
      powerpc/pseries: Fix parent_dn reference leak in add_dt_node() · b537ca6f
      Tyrel Datwyler 提交于
      A reference to the parent device node is held by add_dt_node() for the
      node to be added. If the call to dlpar_configure_connector() fails
      add_dt_node() returns ENOENT and that reference is not freed.
      
      Add a call to of_node_put(parent_dn) prior to bailing out after a
      failed dlpar_configure_connector() call.
      
      Fixes: 8d5ff320 ("powerpc/pseries: Make dlpar_configure_connector parent node aware")
      Cc: stable@vger.kernel.org # v3.12+
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b537ca6f
    • T
      powerpc/pseries: Fix "OF: ERROR: Bad of_node_put() on /cpus" during DLPAR · 087ff6a5
      Tyrel Datwyler 提交于
      Commit 215ee763 ("powerpc: pseries: remove dlpar_attach_node
      dependency on full path") reworked dlpar_attach_node() to no longer
      look up the parent node "/cpus", but instead to have the parent node
      passed by the caller in the function parameter list.
      
      As a result dlpar_attach_node() is no longer responsible for freeing
      the reference to the parent node. However, commit 215ee763 failed
      to remove the of_node_put(parent) call in dlpar_attach_node(), or to
      take into account that the reference to the parent in the caller
      dlpar_cpu_add() needs to be held until after dlpar_attach_node()
      returns.
      
      As a result doing repeated cpu add/remove dlpar operations will
      eventually result in the following error:
      
        OF: ERROR: Bad of_node_put() on /cpus
        CPU: 0 PID: 10896 Comm: drmgr Not tainted 4.13.0-autotest #1
        Call Trace:
         dump_stack+0x15c/0x1f8 (unreliable)
         of_node_release+0x1a4/0x1c0
         kobject_put+0x1a8/0x310
         kobject_del+0xbc/0xf0
         __of_detach_node_sysfs+0x144/0x210
         of_detach_node+0xf0/0x180
         dlpar_detach_node+0xc4/0x120
         dlpar_cpu_remove+0x280/0x560
         dlpar_cpu_release+0xbc/0x1b0
         arch_cpu_release+0x6c/0xb0
         cpu_release_store+0xa0/0x100
         dev_attr_store+0x68/0xa0
         sysfs_kf_write+0xa8/0xf0
         kernfs_fop_write+0x2cc/0x400
         __vfs_write+0x5c/0x340
         vfs_write+0x1a8/0x3d0
         SyS_write+0xa8/0x1a0
         system_call+0x58/0x6c
      
      Fix the issue by removing the of_node_put(parent) call from
      dlpar_attach_node(), and ensuring that the reference to the parent
      node is properly held and released by the caller dlpar_cpu_add().
      
      Fixes: 215ee763 ("powerpc: pseries: remove dlpar_attach_node dependency on full path")
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Reported-by: NAbdul Haleem <abdhalee@linux.vnet.ibm.com>
      [mpe: Add a comment in the code and frob the change log slightly]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      087ff6a5
    • B
      powerpc/eeh: Create PHB PEs after EEH is initialized · 3e77adee
      Benjamin Herrenschmidt 提交于
      Otherwise we end up not yet having computed the right diag data size
      on powernv where EEH initialization is delayed, thus causing memory
      corruption later on when calling OPAL.
      
      Fixes: 5cb1f8fd ("powerpc/powernv/pci: Dynamically allocate PHB diag data")
      Cc: stable@vger.kernel.org # v4.13+
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NRussell Currey <ruscur@russell.cc>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      3e77adee
  6. 20 9月, 2017 13 次提交