1. 26 5月, 2019 8 次提交
  2. 22 5月, 2019 19 次提交
  3. 17 5月, 2019 13 次提交
    • L
      powerpc/booke64: set RI in default MSR · 4179b858
      Laurentiu Tudor 提交于
      commit 5266e58d6cd90ac85c187d673093ad9cb649e16d upstream.
      
      Set RI in the default kernel's MSR so that the architected way of
      detecting unrecoverable machine check interrupts has a chance to work.
      This is inline with the MSR setup of the rest of booke powerpc
      architectures configured here.
      Signed-off-by: NLaurentiu Tudor <laurentiu.tudor@nxp.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4179b858
    • R
      powerpc/powernv/idle: Restore IAMR after idle · 71b20cdb
      Russell Currey 提交于
      commit a3f3072db6cad40895c585dce65e36aab997f042 upstream.
      
      Without restoring the IAMR after idle, execution prevention on POWER9
      with Radix MMU is overwritten and the kernel can freely execute
      userspace without faulting.
      
      This is necessary when returning from any stop state that modifies
      user state, as well as hypervisor state.
      
      To test how this fails without this patch, load the lkdtm driver and
      do the following:
      
        $ echo EXEC_USERSPACE > /sys/kernel/debug/provoke-crash/DIRECT
      
      which won't fault, then boot the kernel with powersave=off, where it
      will fault. Applying this patch will fix this.
      
      Fixes: 3b10d009 ("powerpc/mm/radix: Prevent kernel execution of user space")
      Cc: stable@vger.kernel.org # v4.10+
      Signed-off-by: NRussell Currey <ruscur@russell.cc>
      Reviewed-by: NAkshay Adiga <akshay.adiga@linux.vnet.ibm.com>
      Reviewed-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71b20cdb
    • R
      powerpc/book3s/64: check for NULL pointer in pgd_alloc() · 69c2b71c
      Rick Lindsley 提交于
      commit f39356261c265a0689d7ee568132d516e8b6cecc upstream.
      
      When the memset code was added to pgd_alloc(), it failed to consider
      that kmem_cache_alloc() can return NULL. It's uncommon, but not
      impossible under heavy memory contention. Example oops:
      
        Unable to handle kernel paging request for data at address 0x00000000
        Faulting instruction address: 0xc0000000000a4000
        Oops: Kernel access of bad area, sig: 11 [#1]
        LE SMP NR_CPUS=2048 NUMA pSeries
        CPU: 70 PID: 48471 Comm: entrypoint.sh Kdump: loaded Not tainted 4.14.0-115.6.1.el7a.ppc64le #1
        task: c000000334a00000 task.stack: c000000331c00000
        NIP:  c0000000000a4000 LR: c00000000012f43c CTR: 0000000000000020
        REGS: c000000331c039c0 TRAP: 0300   Not tainted  (4.14.0-115.6.1.el7a.ppc64le)
        MSR:  800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 44022840  XER: 20040000
        CFAR: c000000000008874 DAR: 0000000000000000 DSISR: 42000000 SOFTE: 1
        ...
        NIP [c0000000000a4000] memset+0x68/0x104
        LR [c00000000012f43c] mm_init+0x27c/0x2f0
        Call Trace:
          mm_init+0x260/0x2f0 (unreliable)
          copy_mm+0x11c/0x638
          copy_process.isra.28.part.29+0x6fc/0x1080
          _do_fork+0xdc/0x4c0
          ppc_clone+0x8/0xc
        Instruction dump:
        409e000c b0860000 38c60002 409d000c 90860000 38c60004 78a0d183 78a506a0
        7c0903a6 41820034 60000000 60420000 <f8860000> f8860008 f8860010 f8860018
      
      Fixes: fc5c2f4a ("powerpc/mm/hash64: Zero PGD pages on allocation")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: NRick Lindsley <ricklind@vnet.linux.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      69c2b71c
    • B
      powerpc/64s: Include cpu header · 0dc9ad4e
      Breno Leitao 提交于
      commit 42e2acde1237878462b028f5a27d9cc5bea7502c upstream.
      
      Current powerpc security.c file is defining functions, as
      cpu_show_meltdown(), cpu_show_spectre_v{1,2} and others, that are being
      declared at linux/cpu.h header without including the header file that
      contains these declarations.
      
      This is being reported by sparse, which thinks that these functions are
      static, due to the lack of declaration:
      
      	arch/powerpc/kernel/security.c:105:9: warning: symbol 'cpu_show_meltdown' was not declared. Should it be static?
      	arch/powerpc/kernel/security.c:139:9: warning: symbol 'cpu_show_spectre_v1' was not declared. Should it be static?
      	arch/powerpc/kernel/security.c:161:9: warning: symbol 'cpu_show_spectre_v2' was not declared. Should it be static?
      	arch/powerpc/kernel/security.c:209:6: warning: symbol 'stf_barrier' was not declared. Should it be static?
      	arch/powerpc/kernel/security.c:289:9: warning: symbol 'cpu_show_spec_store_bypass' was not declared. Should it be static?
      
      This patch simply includes the proper header (linux/cpu.h) to match
      function definition and declaration.
      Signed-off-by: NBreno Leitao <leitao@debian.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Cc: Joel Stanley <joel@jms.id.au>
      Cc: Nathan Chancellor <natechancellor@gmail.com>
      Cc: Major Hayden <major@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0dc9ad4e
    • R
      um: Don't hardcode path as it is architecture dependent · db1b4aa6
      Ritesh Raj Sarraf 提交于
      commit 9ca19a3a3e2482916c475b90f3d7fa2a03d8e5ed upstream.
      
      The current code fails to run on amd64 because of hardcoded reference to
      i386
      Signed-off-by: NRitesh Raj Sarraf <rrs@researchut.com>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db1b4aa6
    • M
      x86/kprobes: Avoid kretprobe recursion bug · 57526050
      Masami Hiramatsu 提交于
      [ Upstream commit b191fa96ea6dc00d331dcc28c1f7db5e075693a0 ]
      
      Avoid kretprobe recursion loop bg by setting a dummy
      kprobes to current_kprobe per-CPU variable.
      
      This bug has been introduced with the asm-coded trampoline
      code, since previously it used another kprobe for hooking
      the function return placeholder (which only has a nop) and
      trampoline handler was called from that kprobe.
      
      This revives the old lost kprobe again.
      
      With this fix, we don't see deadlock anymore.
      
      And you can see that all inner-called kretprobe are skipped.
      
        event_1                                  235               0
        event_2                                19375           19612
      
      The 1st column is recorded count and the 2nd is missed count.
      Above shows (event_1 rec) + (event_2 rec) ~= (event_2 missed)
      (some difference are here because the counter is racy)
      Reported-by: NAndrea Righi <righi.andrea@gmail.com>
      Tested-by: NAndrea Righi <righi.andrea@gmail.com>
      Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Fixes: c9becf58 ("[PATCH] kretprobe: kretprobe-booster")
      Link: http://lkml.kernel.org/r/155094064889.6137.972160690963039.stgit@devboxSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <alexander.levin@microsoft.com>
      57526050
    • N
      powerpc/smp: Fix NMI IPI xmon timeout · 19f4f94f
      Nicholas Piggin 提交于
      [ Upstream commit 88b9a3d1425a436e95c41f09986fdae2daee437a ]
      
      The xmon debugger IPI handler waits in the callback function while
      xmon is still active. This means they don't complete the IPI, and the
      initiator always times out waiting for them.
      
      Things manage to work after the timeout because there is some fallback
      logic to keep NMI IPI state sane in case of the timeout, but this is a
      bit ugly.
      
      This patch changes NMI IPI back to half-asynchronous (i.e., wait for
      everyone to call in, do not wait for IPI function to complete), but
      the complexity is avoided by going one step further and allowing new
      IPIs to be issued before the IPI functions to all complete.
      
      If synchronization against that is required, it is left up to the
      caller, but current callers don't require that. In fact with the
      timeout handling, callers must be able to cope with this already.
      
      Fixes: 5b73151f ("powerpc: NMI IPI make NMI IPIs fully sychronous")
      Cc: stable@vger.kernel.org # v4.19+
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <alexander.levin@microsoft.com>
      19f4f94f
    • N
      powerpc/smp: Fix NMI IPI timeout · f8bd34d1
      Nicholas Piggin 提交于
      [ Upstream commit 1b5fc84aba170bdfe3533396ca9662ceea1609b7 ]
      
      The NMI IPI timeout logic is broken, if __smp_send_nmi_ipi() times out
      on the first condition, delay_us will be zero which will send it into
      the second spin loop with no timeout so it will spin forever.
      
      Fixes: 5b73151f ("powerpc: NMI IPI make NMI IPIs fully sychronous")
      Cc: stable@vger.kernel.org # v4.19+
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NSasha Levin <alexander.levin@microsoft.com>
      f8bd34d1
    • T
      ARM: 8856/1: NOMMU: Fix CCR register faulty initialization when MPU is disabled · 3835cb5a
      Tigran Tadevosyan 提交于
      [ Upstream commit c3143967807adb1357c36b68a7563fc0c4e1f615 ]
      
      When CONFIG_ARM_MPU is not defined, the base address of v7M SCB register
      is not initialized with correct value. This prevents enabling I/D caches
      when the L1 cache poilcy is applied in kernel.
      
      Fixes: 3c241210 ("ARM: 8756/1: NOMMU: Postpone MPU activation till __after_proc_init")
      Signed-off-by: NTigran Tadevosyan <tigran.tadevosyan@arm.com>
      Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3835cb5a
    • P
      MIPS: perf: ath79: Fix perfcount IRQ assignment · ca864881
      Petr Štetiar 提交于
      [ Upstream commit a1e8783db8e0d58891681bc1e6d9ada66eae8e20 ]
      
      Currently it's not possible to use perf on ath79 due to genirq flags
      mismatch happening on static virtual IRQ 13 which is used for
      performance counters hardware IRQ 5.
      
      On TP-Link Archer C7v5:
      
                 CPU0
        2:          0      MIPS   2  ath9k
        4:        318      MIPS   4  19000000.eth
        7:      55034      MIPS   7  timer
        8:       1236      MISC   3  ttyS0
       12:          0      INTC   1  ehci_hcd:usb1
       13:          0  gpio-ath79   2  keys
       14:          0  gpio-ath79   5  keys
       15:         31  AR724X PCI    1  ath10k_pci
      
       $ perf top
       genirq: Flags mismatch irq 13. 00014c83 (mips_perf_pmu) vs. 00002003 (keys)
      
      On TP-Link Archer C7v4:
      
               CPU0
        4:          0      MIPS   4  19000000.eth
        5:       7135      MIPS   5  1a000000.eth
        7:      98379      MIPS   7  timer
        8:         30      MISC   3  ttyS0
       12:      90028      INTC   0  ath9k
       13:       5520      INTC   1  ehci_hcd:usb1
       14:       4623      INTC   2  ehci_hcd:usb2
       15:      32844  AR724X PCI    1  ath10k_pci
       16:          0  gpio-ath79  16  keys
       23:          0  gpio-ath79  23  keys
      
       $ perf top
       genirq: Flags mismatch irq 13. 00014c80 (mips_perf_pmu) vs. 00000080 (ehci_hcd:usb1)
      
      This problem is happening, because currently statically assigned virtual
      IRQ 13 for performance counters is not claimed during the initialization
      of MIPS PMU during the bootup, so the IRQ subsystem doesn't know, that
      this interrupt isn't available for further use.
      
      So this patch fixes the issue by simply booking hardware IRQ 5 for MIPS PMU.
      Tested-by: NKevin 'ldir' Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
      Signed-off-by: NPetr Štetiar <ynezz@true.cz>
      Acked-by: NJohn Crispin <john@phrozen.org>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ca864881
    • V
      KVM: x86: avoid misreporting level-triggered irqs as edge-triggered in tracing · 0c8afd51
      Vitaly Kuznetsov 提交于
      [ Upstream commit 7a223e06b1a411cef6c4cd7a9b9a33c8d225b10e ]
      
      In __apic_accept_irq() interface trig_mode is int and actually on some code
      paths it is set above u8:
      
      kvm_apic_set_irq() extracts it from 'struct kvm_lapic_irq' where trig_mode
      is u16. This is done on purpose as e.g. kvm_set_msi_irq() sets it to
      (1 << 15) & e->msi.data
      
      kvm_apic_local_deliver sets it to reg & (1 << 15).
      
      Fix the immediate issue by making 'tm' into u16. We may also want to adjust
      __apic_accept_irq() interface and use proper sizes for vector, level,
      trig_mode but this is not urgent.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0c8afd51
    • P
      KVM: fix spectrev1 gadgets · d39f3cc7
      Paolo Bonzini 提交于
      [ Upstream commit 1d487e9bf8ba66a7174c56a0029c54b1eca8f99c ]
      
      These were found with smatch, and then generalized when applicable.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d39f3cc7
    • J
      x86/reboot, efi: Use EFI reboot for Acer TravelMate X514-51T · 4074bc37
      Jian-Hong Pan 提交于
      [ Upstream commit 0082517fa4bce073e7cf542633439f26538a14cc ]
      
      Upon reboot, the Acer TravelMate X514-51T laptop appears to complete the
      shutdown process, but then it hangs in BIOS POST with a black screen.
      
      The problem is intermittent - at some points it has appeared related to
      Secure Boot settings or different kernel builds, but ultimately we have
      not been able to identify the exact conditions that trigger the issue to
      come and go.
      
      Besides, the EFI mode cannot be disabled in the BIOS of this model.
      
      However, after extensive testing, we observe that using the EFI reboot
      method reliably avoids the issue in all cases.
      
      So add a boot time quirk to use EFI reboot on such systems.
      
      Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=203119Signed-off-by: NJian-Hong Pan <jian-hong@endlessm.com>
      Signed-off-by: NDaniel Drake <drake@endlessm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Cc: linux@endlessm.com
      Link: http://lkml.kernel.org/r/20190412080152.3718-1-jian-hong@endlessm.com
      [ Fix !CONFIG_EFI build failure, clarify the code and the changelog a bit. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4074bc37