1. 02 11月, 2017 12 次提交
  2. 31 10月, 2017 1 次提交
  3. 27 10月, 2017 3 次提交
    • I
      Revert "x86/mm: Limit mmap() of /dev/mem to valid physical addresses" · 90edaac6
      Ingo Molnar 提交于
      This reverts commit ce56a86e.
      
      There's unanticipated interaction with some boot parameters like 'mem=',
      which now cause the new checks via valid_mmap_phys_addr_range() to be too
      restrictive, crashing a Qemu bootup in fact, as reported by Fengguang Wu.
      
      So while the motivation of the change is still entirely valid, we
      need a few more rounds of testing to get it right - it's way too late
      after -rc6, so revert it for now.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NCraig Bergstrom <craigb@google.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: 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>
      Cc: dsafonov@virtuozzo.com
      Cc: kirill.shutemov@linux.intel.com
      Cc: mhocko@suse.com
      Cc: oleg@redhat.com
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      90edaac6
    • S
      arm/xen: don't inclide rwlock.h directly. · a494ee6c
      Sebastian Andrzej Siewior 提交于
      rwlock.h should not be included directly. Instead linux/splinlock.h
      should be included. One thing it does is to break the RT build.
      
      Cc: Stefano Stabellini <sstabellini@kernel.org>
      Cc: xen-devel@lists.xenproject.org
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      a494ee6c
    • L
      alpha/PCI: Move pci_map_irq()/pci_swizzle() out of initdata · 814eae59
      Lorenzo Pieralisi 提交于
      The introduction of {map/swizzle}_irq() hooks in the struct pci_host_bridge
      allowed to replace the pci_fixup_irqs() PCI IRQ allocation in alpha arch
      PCI code with per-bridge map/swizzle functions with commit 0e4c2eeb
      ("alpha/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping
      hooks").
      
      As a side effect of converting PCI IRQ allocation to the struct
      pci_host_bridge {map/swizzle}_irq() hooks mechanism, the actual PCI IRQ
      allocation function (ie pci_assign_irq()) is carried out per-device in
      pci_device_probe() that is called when a PCI device driver is about to be
      probed.
      
      This means that, for drivers compiled as loadable modules, the actual PCI
      device IRQ allocation can now happen after the system has booted so the
      struct pci_host_bridge {map/swizzle}_irq() hooks pci_assign_irq() relies on
      must stay valid after the system has booted so that PCI core can carry out
      PCI IRQ allocation correctly.
      
      Most of the alpha board structures pci_map_irq() and pci_swizzle() hooks
      (that are used to initialize their struct pci_host_bridge equivalent
      through the alpha_mv global variable - that represents the struct
      alpha_machine_vector of the running kernel) are marked as
      __init/__initdata; this causes freed memory dereferences when PCI IRQ
      allocation is carried out after the kernel has booted (ie when loading PCI
      drivers as loadable module) because when the kernel tries to bind the PCI
      device to its (module) driver, the function pci_assign_irq() is called,
      that in turn retrieves the struct pci_host_bridge {map/swizzle}_irq() hooks
      to carry out PCI IRQ allocation; if those hooks are marked as __init
      code/__initdata they point at freed/invalid memory.
      
      Fix the issue by removing the __init/__initdata markers from all subarch
      struct alpha_machine_vector.pci_map_irq()/pci_swizzle() functions (and
      data).
      
      Fixes: 0e4c2eeb ("alpha/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks")
      Link: http://lkml.kernel.org/r/alpine.LRH.2.21.1710251043170.7098@math.ut.eeReported-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Meelis Roos <mroos@linux.ee>
      Cc: Matt Turner <mattst88@gmail.com>
      814eae59
  4. 25 10月, 2017 1 次提交
    • M
      s390/kvm: fix detection of guest machine checks · 0a5e2ec2
      Martin Schwidefsky 提交于
      The new detection code for guest machine checks added a check based
      on %r11 to .Lcleanup_sie to distinguish between normal asynchronous
      interrupts and machine checks. But the funtion is called from the
      program check handler as well with an undefined value in %r11.
      
      The effect is that all program exceptions pointing to the SIE instruction
      will set the CIF_MCCK_GUEST bit. The bit stays set for the CPU until the
       next machine check comes in which will incorrectly be interpreted as a
      guest machine check.
      
      The simplest fix is to stop using .Lcleanup_sie in the program check
      handler and duplicate a few instructions.
      
      Fixes: c929500d ("s390/nmi: s390: New low level handling for machine check happening in guest")
      Cc: <stable@vger.kernel.org> # v4.13+
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      0a5e2ec2
  5. 24 10月, 2017 1 次提交
  6. 23 10月, 2017 3 次提交
  7. 22 10月, 2017 1 次提交
  8. 20 10月, 2017 2 次提交
    • D
      x86/entry: Use SYSCALL_DEFINE() macros for sys_modify_ldt() · da20ab35
      Dave Hansen 提交于
      We do not have tracepoints for sys_modify_ldt() because we define
      it directly instead of using the normal SYSCALL_DEFINEx() macros.
      
      However, there is a reason sys_modify_ldt() does not use the macros:
      it has an 'int' return type instead of 'unsigned long'.  This is
      a bug, but it's a bug cemented in the ABI.
      
      What does this mean?  If we return -EINVAL from a function that
      returns 'int', we have 0x00000000ffffffea in %rax.  But, if we
      return -EINVAL from a function returning 'unsigned long', we end
      up with 0xffffffffffffffea in %rax, which is wrong.
      
      To work around this and maintain the 'int' behavior while using
      the SYSCALL_DEFINEx() macros, so we add a cast to 'unsigned int'
      in both implementations of sys_modify_ldt().
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Reviewed-by: NAndy Lutomirski <luto@kernel.org>
      Reviewed-by: NBrian Gerst <brgerst@gmail.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/20171018172107.1A79C532@viggo.jf.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      da20ab35
    • C
      x86/mm: Limit mmap() of /dev/mem to valid physical addresses · ce56a86e
      Craig Bergstrom 提交于
      Currently, it is possible to mmap() any offset from /dev/mem.  If a
      program mmaps() /dev/mem offsets outside of the addressable limits
      of a system, the page table can be corrupted by setting reserved bits.
      
      For example if you mmap() offset 0x0001000000000000 of /dev/mem on an
      x86_64 system with a 48-bit bus, the page fault handler will be called
      with error_code set to RSVD.  The kernel then crashes with a page table
      corruption error.
      
      This change prevents this page table corruption on x86 by refusing
      to mmap offsets higher than the highest valid address in the system.
      Signed-off-by: NCraig Bergstrom <craigb@google.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: 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>
      Cc: dsafonov@virtuozzo.com
      Cc: kirill.shutemov@linux.intel.com
      Cc: mhocko@suse.com
      Cc: oleg@redhat.com
      Link: http://lkml.kernel.org/r/20171019192856.39672-1-craigb@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ce56a86e
  9. 19 10月, 2017 6 次提交
  10. 18 10月, 2017 6 次提交
  11. 17 10月, 2017 4 次提交