Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 02 11月, 2017 22 次提交
  3. 31 10月, 2017 1 次提交
  5. 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
  7. 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
  9. 24 10月, 2017 1 次提交
  11. 23 10月, 2017 3 次提交
  13. 22 10月, 2017 1 次提交
  15. 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
  17. 19 10月, 2017 6 次提交