1. 01 Apr, 2019 4 commits
  2. 23 Feb, 2019 2 commits
    • Joerg Roedel's avatar
      KVM: VMX: Fix x2apic check in vmx_msr_bitmap_mode() · 49e1a9d1
      Joerg Roedel authored
      The stable backport of upstream commit
      
      	904e14fb KVM: VMX: make MSR bitmaps per-VCPU
      
      has a bug in vmx_msr_bitmap_mode(). It enables the x2apic
      MSR-bitmap when the kernel emulates x2apic for the guest in
      software. The upstream version of the commit checkes whether
      the hardware has virtualization enabled for x2apic
      emulation.
      
      Since KVM emulates x2apic for guests even when the host does
      not support x2apic in hardware, this causes the intercept of
      at least the X2APIC_TASKPRI MSR to be disabled on machines
      not supporting that MSR. The result is undefined behavior,
      on some machines (Intel Westmere based) it causes a crash of
      the guest kernel when it tries to access that MSR.
      
      Change the check in vmx_msr_bitmap_mode() to match the upstream
      code. This fixes the guest crashes observed with stable
      kernels starting with v4.4.168 through v4.4.175.
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49e1a9d1
    • chenzefeng (A)'s avatar
      x86: livepatch: Treat R_X86_64_PLT32 as R_X86_64_PC32 · f5aebe74
      chenzefeng (A) authored
      Signed-off-by: default avatarchenzefeng <chenzefeng2@huawei.com>
      
      On x86-64, for 32-bit PC-relacive branches, we can generate PLT32
      relocation, instead of PC32 relocation. and R_X86_64_PLT32 can be
      treated the same as R_X86_64_PC32 since linux kernel doesn't use PLT.
      
      commit b21ebf2f ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") been
      fixed for the module loading, but not fixed for livepatch relocation,
      which will fail to load livepatch with the error message as follow:
      relocation failed for symbol <symbol name> at <symbol address>
      
      This issue only effacted the kernel version from 4.0 to 4.6, becauce the
      function klp_write_module_reloc is introduced by: commit b700e7f0
      ("livepatch: kernel: add support for live patching") and deleted by:
      commit 425595a7 ("livepatch: reuse module loader code to write
      relocations")
      Signed-off-by: default avatarchenzefeng <chenzefeng2@huawei.com>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5aebe74
  3. 20 Feb, 2019 29 commits
    • Borislav Petkov's avatar
      x86/a.out: Clear the dump structure initially · 5079b1d1
      Borislav Petkov authored
      commit 10970e1b4be9c74fce8ab6e3c34a7d718f063f2c upstream.
      
      dump_thread32() in aout_core_dump() does not clear the user32 structure
      allocated on the stack as the first thing on function entry.
      
      As a result, the dump.u_comm, dump.u_ar0 and dump.signal which get
      assigned before the clearing, get overwritten.
      
      Rename that function to fill_dump() to make it clear what it does and
      call it first thing.
      
      This was caught while staring at a patch by Derek Robson
      <robsonde@gmail.com>.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Derek Robson <robsonde@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Matz <matz@suse.de>
      Cc: x86@kernel.org
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20190202005512.3144-1-robsonde@gmail.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5079b1d1
    • Hedi Berriche's avatar
      x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls · 7212e37c
      Hedi Berriche authored
      commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream.
      
      Calls into UV firmware must be protected against concurrency, expose the
      efi_runtime_lock to the UV platform, and use it to serialise UV BIOS
      calls.
      Signed-off-by: default avatarHedi Berriche <hedi.berriche@hpe.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: default avatarRuss Anderson <rja@hpe.com>
      Reviewed-by: default avatarDimitri Sivanich <sivanich@hpe.com>
      Reviewed-by: default avatarMike Travis <mike.travis@hpe.com>
      Cc: Andy Shevchenko <andy@infradead.org>
      Cc: Bhupesh Sharma <bhsharma@redhat.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-efi <linux-efi@vger.kernel.org>
      Cc: platform-driver-x86@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.9+
      Cc: Steve Wahl <steve.wahl@hpe.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7212e37c
    • Meelis Roos's avatar
      alpha: Fix Eiger NR_IRQS to 128 · 5fc95186
      Meelis Roos authored
      commit bfc913682464f45bc4d6044084e370f9048de9d5 upstream.
      
      Eiger machine vector definition has nr_irqs 128, and working 2.6.26
      boot shows SCSI getting IRQ-s 64 and 65. Current kernel boot fails
      because Symbios SCSI fails to request IRQ-s and does not find the disks.
      It has been broken at least since 3.18 - the earliest I could test with
      my gcc-5.
      
      The headers have moved around and possibly another order of defines has
      worked in the past - but since 128 seems to be correct and used, fix
      arch/alpha/include/asm/irq.h to have NR_IRQS=128 for Eiger.
      
      This fixes 4.19-rc7 boot on my Force Flexor A264 (Eiger subarch).
      
      Cc: stable@vger.kernel.org # v3.18+
      Signed-off-by: default avatarMeelis Roos <mroos@linux.ee>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5fc95186
    • Sergei Trofimovich's avatar
      alpha: fix page fault handling for r16-r18 targets · 1d8b2030
      Sergei Trofimovich authored
      commit 491af60ffb848b59e82f7c9145833222e0bf27a5 upstream.
      
      Fix page fault handling code to fixup r16-r18 registers.
      Before the patch code had off-by-two registers bug.
      This bug caused overwriting of ps,pc,gp registers instead
      of fixing intended r16,r17,r18 (see `struct pt_regs`).
      
      More details:
      
      Initially Dmitry noticed a kernel bug as a failure
      on strace test suite. Test passes unmapped userspace
      pointer to io_submit:
      
      ```c
          #include <err.h>
          #include <unistd.h>
          #include <sys/mman.h>
          #include <asm/unistd.h>
          int main(void)
          {
              unsigned long ctx = 0;
              if (syscall(__NR_io_setup, 1, &ctx))
                  err(1, "io_setup");
              const size_t page_size = sysconf(_SC_PAGESIZE);
              const size_t size = page_size * 2;
              void *ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
                               MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
              if (MAP_FAILED == ptr)
                  err(1, "mmap(%zu)", size);
              if (munmap(ptr, size))
                  err(1, "munmap");
              syscall(__NR_io_submit, ctx, 1, ptr + page_size);
              syscall(__NR_io_destroy, ctx);
              return 0;
          }
      ```
      
      Running this test causes kernel to crash when handling page fault:
      
      ```
          Unable to handle kernel paging request at virtual address ffffffffffff9468
          CPU 3
          aio(26027): Oops 0
          pc = [<fffffc00004eddf8>]  ra = [<fffffc00004edd5c>]  ps = 0000    Not tainted
          pc is at sys_io_submit+0x108/0x200
          ra is at sys_io_submit+0x6c/0x200
          v0 = fffffc00c58e6300  t0 = fffffffffffffff2  t1 = 000002000025e000
          t2 = fffffc01f159fef8  t3 = fffffc0001009640  t4 = fffffc0000e0f6e0
          t5 = 0000020001002e9e  t6 = 4c41564e49452031  t7 = fffffc01f159c000
          s0 = 0000000000000002  s1 = 000002000025e000  s2 = 0000000000000000
          s3 = 0000000000000000  s4 = 0000000000000000  s5 = fffffffffffffff2
          s6 = fffffc00c58e6300
          a0 = fffffc00c58e6300  a1 = 0000000000000000  a2 = 000002000025e000
          a3 = 00000200001ac260  a4 = 00000200001ac1e8  a5 = 0000000000000001
          t8 = 0000000000000008  t9 = 000000011f8bce30  t10= 00000200001ac440
          t11= 0000000000000000  pv = fffffc00006fd320  at = 0000000000000000
          gp = 0000000000000000  sp = 00000000265fd174
          Disabling lock debugging due to kernel taint
          Trace:
          [<fffffc0000311404>] entSys+0xa4/0xc0
      ```
      
      Here `gp` has invalid value. `gp is s overwritten by a fixup for the
      following page fault handler in `io_submit` syscall handler:
      
      ```
          __se_sys_io_submit
          ...
              ldq     a1,0(t1)
              bne     t0,4280 <__se_sys_io_submit+0x180>
      ```
      
      After a page fault `t0` should contain -EFALUT and `a1` is 0.
      Instead `gp` was overwritten in place of `a1`.
      
      This happens due to a off-by-two bug in `dpf_reg()` for `r16-r18`
      (aka `a0-a2`).
      
      I think the bug went unnoticed for a long time as `gp` is one
      of scratch registers. Any kernel function call would re-calculate `gp`.
      
      Dmitry tracked down the bug origin back to 2.1.32 kernel version
      where trap_a{0,1,2} fields were inserted into struct pt_regs.
      And even before that `dpf_reg()` contained off-by-one error.
      
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Reported-and-reviewed-by: default avatar"Dmitry V. Levin" <ldv@altlinux.org>
      Cc: stable@vger.kernel.org # v2.1.32+
      Bug: https://bugs.gentoo.org/672040Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      Signed-off-by: default avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1d8b2030
    • Nicholas Mc Guire's avatar
      gpio: pl061: handle failed allocations · 83476701
      Nicholas Mc Guire authored
      [ Upstream commit df209c43a0e8258e096fb722dfbdae4f0dd13fde ]
      
      devm_kzalloc(), devm_kstrdup() and devm_kasprintf() all can
      fail internal allocation and return NULL. Using any of the assigned
      objects without checking is not safe. As this is early in the boot
      phase and these allocations really should not fail, any failure here
      is probably an indication of a more serious issue so it makes little
      sense to try and rollback the previous allocated resources or try to
      continue;  but rather the probe function is simply exited with -ENOMEM.
      Signed-off-by: default avatarNicholas Mc Guire <hofrat@osadl.org>
      Fixes: 684284b6 ("ARM: integrator: add MMCI device to IM-PD1")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      83476701
    • Linus Walleij's avatar
      ARM: dts: kirkwood: Fix polarity of GPIO fan lines · 32f04710
      Linus Walleij authored
      [ Upstream commit b5f034845e70916fd33e172fad5ad530a29c10ab ]
      
      These two lines are active high, not active low. The bug was
      found when we changed the kernel to respect the polarity defined
      in the device tree.
      
      Fixes: 1b90e06b ("ARM: kirkwood: Use devicetree to define DNS-32[05] fan")
      Cc: Jamie Lentin <jm@lentin.co.uk>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Gregory Clement <gregory.clement@bootlin.com>
      Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Cc: Julien D'Ascenzio <jdascenzio@posteo.net>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Tested-by: default avatarJamie Lentin <jm@lentin.co.uk>
      Reported-by: default avatarJulien D'Ascenzio <jdascenzio@posteo.net>
      Tested-by: default avatarJulien D'Ascenzio <jdascenzio@posteo.net>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@bootlin.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      32f04710
    • Peter Ujfalusi's avatar
      ARM: dts: da850-evm: Correct the sound card name · 20ad5046
      Peter Ujfalusi authored
      [ Upstream commit 7fca69d4e43fa1ae9cb4f652772c132dc5a659c6 ]
      
      To avoid  the following error:
      asoc-simple-card sound: ASoC: Failed to create card debugfs directory
      
      Which is because the card name contains '/' character, which can not be
      used in file or directory names.
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      20ad5046
    • Russell King's avatar
      ARM: iop32x/n2100: fix PCI IRQ mapping · fd9d0553
      Russell King authored
      commit db4090920ba2d61a5827a23e441447926a02ffee upstream.
      
      Booting 4.20 on a TheCUS N2100 results in a kernel oops while probing
      PCI, due to n2100_pci_map_irq() having been discarded during boot.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Cc: stable@vger.kernel.org # 2.6.18+
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd9d0553
    • Paul Burton's avatar
      MIPS: VDSO: Include $(ccflags-vdso) in o32,n32 .lds builds · dfb35362
      Paul Burton authored
      commit 67fc5dc8a541e8f458d7f08bf88ff55933bf9f9d upstream.
      
      When generating vdso-o32.lds & vdso-n32.lds for use with programs
      running as compat ABIs under 64b kernels, we previously haven't included
      the compiler flags that are supposedly common to all ABIs - ie. those in
      the ccflags-vdso variable.
      
      This is problematic in cases where we need to provide the -m%-float flag
      in order to ensure that we don't attempt to use a floating point ABI
      that's incompatible with the target CPU & ABI. For example a toolchain
      using current gcc trunk configured --with-fp-32=xx fails to build a
      64r6el_defconfig kernel with the following error:
      
        cc1: error: '-march=mips1' requires '-mfp32'
        make[2]: *** [arch/mips/vdso/Makefile:135: arch/mips/vdso/vdso-o32.lds] Error 1
      
      Include $(ccflags-vdso) for the compat VDSO .lds builds, just as it is
      included for the native VDSO .lds & when compiling objects for the
      compat VDSOs. This ensures we consistently provide the -msoft-float flag
      amongst others, avoiding the problem by ensuring we're agnostic to the
      toolchain defaults.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: ebb5e78c ("MIPS: Initial implementation of a VDSO")
      Cc: linux-mips@vger.kernel.org
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Maciej W . Rozycki <macro@linux-mips.org>
      Cc: stable@vger.kernel.org # v4.4+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfb35362
    • Aaro Koskinen's avatar
      MIPS: OCTEON: don't set octeon_dma_bar_type if PCI is disabled · 91aaa0dd
      Aaro Koskinen authored
      commit dcf300a69ac307053dfb35c2e33972e754a98bce upstream.
      
      Don't set octeon_dma_bar_type if PCI is disabled. This avoids creation
      of the MSI irqchip later on, and saves a bit of memory.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Fixes: a214720cbf50 ("Disable MSI also when pcie-octeon.pcie_disable on")
      Cc: stable@vger.kernel.org # v3.3+
      Cc: linux-mips@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91aaa0dd
    • Vladimir Kondratiev's avatar
      mips: cm: reprime error cause · d93fdf44
      Vladimir Kondratiev authored
      commit 05dc6001af0630e200ad5ea08707187fe5537e6d upstream.
      
      Accordingly to the documentation
      ---cut---
      The GCR_ERROR_CAUSE.ERR_TYPE field and the GCR_ERROR_MULT.ERR_TYPE
      fields can be cleared by either a reset or by writing the current
      value of GCR_ERROR_CAUSE.ERR_TYPE to the
      GCR_ERROR_CAUSE.ERR_TYPE register.
      ---cut---
      Do exactly this. Original value of cm_error may be safely written back;
      it clears error cause and keeps other bits untouched.
      
      Fixes: 3885c2b4 ("MIPS: CM: Add support for reporting CM cache errors")
      Signed-off-by: default avatarVladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: stable@vger.kernel.org # v4.3+
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d93fdf44
    • Tony Luck's avatar
      x86/MCE: Initialize mce.bank in the case of a fatal error in mce_no_way_out() · 122c0149
      Tony Luck authored
      commit d28af26faa0b1daf3c692603d46bc4687c16f19e upstream.
      
      Internal injection testing crashed with a console log that said:
      
        mce: [Hardware Error]: CPU 7: Machine Check Exception: f Bank 0: bd80000000100134
      
      This caused a lot of head scratching because the MCACOD (bits 15:0) of
      that status is a signature from an L1 data cache error. But Linux says
      that it found it in "Bank 0", which on this model CPU only reports L1
      instruction cache errors.
      
      The answer was that Linux doesn't initialize "m->bank" in the case that
      it finds a fatal error in the mce_no_way_out() pre-scan of banks. If
      this was a local machine check, then this partially initialized struct
      mce is being passed to mce_panic().
      
      Fix is simple: just initialize m->bank in the case of a fatal error.
      
      Fixes: 40c36e2741d7 ("x86/mce: Fix incorrect "Machine check from unknown source" message")
      Signed-off-by: default avatarTony Luck <tony.luck@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: Vishal Verma <vishal.l.verma@intel.com>
      Cc: x86-ml <x86@kernel.org>
      Cc: stable@vger.kernel.org # v4.18 Note pre-v5.0 arch/x86/kernel/cpu/mce/core.c was called arch/x86/kernel/cpu/mcheck/mce.c
      Link: https://lkml.kernel.org/r/20190201003341.10638-1-tony.luck@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      122c0149
    • Kan Liang's avatar
      perf/x86/intel/uncore: Add Node ID mask · 00025153
      Kan Liang authored
      commit 9e63a7894fd302082cf3627fe90844421a6cbe7f upstream.
      
      Some PCI uncore PMUs cannot be registered on an 8-socket system (HPE
      Superdome Flex).
      
      To understand which Socket the PCI uncore PMUs belongs to, perf retrieves
      the local Node ID of the uncore device from CPUNODEID(0xC0) of the PCI
      configuration space, and the mapping between Socket ID and Node ID from
      GIDNIDMAP(0xD4). The Socket ID can be calculated accordingly.
      
      The local Node ID is only available at bit 2:0, but current code doesn't
      mask it. If a BIOS doesn't clear the rest of the bits, an incorrect Node ID
      will be fetched.
      
      Filter the Node ID by adding a mask.
      Reported-by: default avatarSong Liu <songliubraving@fb.com>
      Tested-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org> # v3.7+
      Fixes: 7c94ee2e ("perf/x86: Add Intel Nehalem and Sandy Bridge-EP uncore support")
      Link: https://lkml.kernel.org/r/1548600794-33162-1-git-send-email-kan.liang@linux.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      00025153
    • Peter Shier's avatar
      KVM: nVMX: unconditionally cancel preemption timer in free_nested (CVE-2019-7221) · 9872ddae
      Peter Shier authored
      commit ecec76885bcfe3294685dc363fd1273df0d5d65f upstream.
      
      Bugzilla: 1671904
      
      There are multiple code paths where an hrtimer may have been started to
      emulate an L1 VMX preemption timer that can result in a call to free_nested
      without an intervening L2 exit where the hrtimer is normally
      cancelled. Unconditionally cancel in free_nested to cover all cases.
      
      Embargoed until Feb 7th 2019.
      Signed-off-by: default avatarPeter Shier <pshier@google.com>
      Reported-by: default avatarJim Mattson <jmattson@google.com>
      Reviewed-by: default avatarJim Mattson <jmattson@google.com>
      Reported-by: default avatarFelix Wilhelm <fwilhelm@google.com>
      Cc: stable@kernel.org
      Message-Id: <20181011184646.154065-1-pshier@google.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9872ddae
    • Paolo Bonzini's avatar
      KVM: x86: work around leak of uninitialized stack contents (CVE-2019-7222) · 1b5fd913
      Paolo Bonzini authored
      commit 353c0956a618a07ba4bbe7ad00ff29fe70e8412a upstream.
      
      Bugzilla: 1671930
      
      Emulation of certain instructions (VMXON, VMCLEAR, VMPTRLD, VMWRITE with
      memory operand, INVEPT, INVVPID) can incorrectly inject a page fault
      when passed an operand that points to an MMIO address.  The page fault
      will use uninitialized kernel stack memory as the CR2 and error code.
      
      The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
      exit to userspace; however, it is not an easy fix, so for now just
      ensure that the error code and CR2 are zero.
      
      Embargoed until Feb 7th 2019.
      Reported-by: default avatarFelix Wilhelm <fwilhelm@google.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b5fd913
    • Anton Ivanov's avatar
      um: Avoid marking pages with "changed protection" · ccc9ed24
      Anton Ivanov authored
      [ Upstream commit 8892d8545f2d0342b9c550defbfb165db237044b ]
      
      Changing protection is a very high cost operation in UML
      because in addition to an extra syscall it also interrupts
      mmap merge sequences generated by the tlb.
      
      While the condition is not particularly common it is worth
      avoiding.
      Signed-off-by: default avatarAnton Ivanov <anton.ivanov@cambridgegreys.com>
      Signed-off-by: Richard Weinberger's avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ccc9ed24
    • Vitaly Kuznetsov's avatar
      KVM: x86: svm: report MSR_IA32_MCG_EXT_CTL as unsupported · a8014f27
      Vitaly Kuznetsov authored
      [ Upstream commit e87555e550cef4941579cd879759a7c0dee24e68 ]
      
      AMD doesn't seem to implement MSR_IA32_MCG_EXT_CTL and svm code in kvm
      knows nothing about it, however, this MSR is among emulated_msrs and
      thus returned with KVM_GET_MSR_INDEX_LIST. The consequent KVM_GET_MSRS,
      of course, fails.
      
      Report the MSR as unsupported to not confuse userspace.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a8014f27
    • Christophe Leroy's avatar
      powerpc/uaccess: fix warning/error with access_ok() · 3df04b50
      Christophe Leroy authored
      [ Upstream commit 05a4ab823983d9136a460b7b5e0d49ee709a6f86 ]
      
      With the following piece of code, the following compilation warning
      is encountered:
      
      	if (_IOC_DIR(ioc) != _IOC_NONE) {
      		int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ;
      
      		if (!access_ok(verify, ioarg, _IOC_SIZE(ioc))) {
      
      drivers/platform/test/dev.c: In function 'my_ioctl':
      drivers/platform/test/dev.c:219:7: warning: unused variable 'verify' [-Wunused-variable]
         int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ;
      
      This patch fixes it by referencing 'type' in the macro allthough
      doing nothing with it.
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3df04b50
    • Mark Rutland's avatar
      arm64: KVM: Skip MMIO insn after emulation · fac39ee2
      Mark Rutland authored
      [ Upstream commit 0d640732dbebed0f10f18526de21652931f0b2f2 ]
      
      When we emulate an MMIO instruction, we advance the CPU state within
      decode_hsr(), before emulating the instruction effects.
      
      Having this logic in decode_hsr() is opaque, and advancing the state
      before emulation is problematic. It gets in the way of applying
      consistent single-step logic, and it prevents us from being able to fail
      an MMIO instruction with a synchronous exception.
      
      Clean this up by only advancing the CPU state *after* the effects of the
      instruction are emulated.
      
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      fac39ee2
    • Arnd Bergmann's avatar
      ARM: pxa: avoid section mismatch warning · b9037406
      Arnd Bergmann authored
      [ Upstream commit 88af3209aa0881aa5ffd99664b6080a4be5f24e5 ]
      
      WARNING: vmlinux.o(.text+0x19f90): Section mismatch in reference from the function littleton_init_lcd() to the function .init.text:pxa_set_fb_info()
      The function littleton_init_lcd() references
      the function __init pxa_set_fb_info().
      This is often because littleton_init_lcd lacks a __init
      annotation or the annotation of pxa_set_fb_info is wrong.
      
      WARNING: vmlinux.o(.text+0xf824): Section mismatch in reference from the function zeus_register_ohci() to the function .init.text:pxa_set_ohci_info()
      The function zeus_register_ohci() references
      the function __init pxa_set_ohci_info().
      This is often because zeus_register_ohci lacks a __init
      annotation or the annotation of pxa_set_ohci_info is wrong.
      
      WARNING: vmlinux.o(.text+0xf95c): Section mismatch in reference from the function cm_x300_init_u2d() to the function .init.text:pxa3xx_set_u2d_info()
      The function cm_x300_init_u2d() references
      the function __init pxa3xx_set_u2d_info().
      This is often because cm_x300_init_u2d lacks a __init
      annotation or the annotation of pxa3xx_set_u2d_info is wrong.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b9037406
    • Jiong Wang's avatar
      mips: bpf: fix encoding bug for mm_srlv32_op · cab345f0
      Jiong Wang authored
      [ Upstream commit 17f6c83fb5ebf7db4fcc94a5be4c22d5a7bfe428 ]
      
      For micro-mips, srlv inside POOL32A encoding space should use 0x50
      sub-opcode, NOT 0x90.
      
      Some early version ISA doc describes the encoding as 0x90 for both srlv and
      srav, this looks to me was a typo. I checked Binutils libopcode
      implementation which is using 0x50 for srlv and 0x90 for srav.
      
      v1->v2:
        - Keep mm_srlv32_op sorted by value.
      
      Fixes: f31318fd ("MIPS: uasm: Add srlv uasm instruction")
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: linux-mips@vger.kernel.org
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarJiong Wang <jiong.wang@netronome.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cab345f0
    • Russell King - ARM Linux's avatar
      ARM: dts: Fix OMAP4430 SDP Ethernet startup · 54b53c59
      Russell King - ARM Linux authored
      [ Upstream commit 84fb6c7feb1494ebb7d1ec8b95cfb7ada0264465 ]
      
      It was noticed that unbinding and rebinding the KSZ8851 ethernet
      resulted in the driver reporting "failed to read device ID" at probe.
      Probing the reset line with a 'scope while repeatedly attempting to
      bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is
      constantly held at zero, meaning the device is held in reset, and
      does not respond on the SPI bus.
      
      Experimentation with the startup delay on the regulator set to 50ms
      shows that the reset is positively released after 20ms.
      
      Schematics for this board are not available, and the traces are buried
      in the inner layers of the board which makes tracing where the RSTN pin
      extremely difficult.  We can only guess that the RSTN pin is wired to a
      reset generator chip driven off the ethernet supply, which fits the
      observed behaviour.
      
      Include this delay in the regulator startup delay - effectively
      treating the reset as a "supply stable" indicator.
      
      This can not be modelled as a delay in the KSZ8851 driver since the
      reset generation is board specific - if the RSTN pin had been wired to
      a GPIO, reset could be released earlier via the already provided support
      in the KSZ8851 driver.
      
      This also got confirmed by Peter Ujfalusi <peter.ujfalusi@ti.com> based
      on Blaze schematics that should be very close to SDP4430:
      
      TPS22902YFPR is used as the regulator switch (gpio48 controlled):
      Convert arm boot_lock to raw The VOUT is routed to TPS3808G01DBV.
      (SCH Note: Threshold set at 90%. Vsense: 0.405V).
      
      According to the TPS3808 data sheet the RESET delay time when Ct is
      open (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      [tony@atomide.com: updated with notes from schematics from Peter]
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      54b53c59
    • Sebastian Andrzej Siewior's avatar
      x86/fpu: Add might_fault() to user_insn() · 028f17e0
      Sebastian Andrzej Siewior authored
      [ Upstream commit 6637401c35b2f327a35d27f44bda05e327f2f017 ]
      
      Every user of user_insn() passes an user memory pointer to this macro.
      
      Add might_fault() to user_insn() so we can spot users which are using
      this macro in sections where page faulting is not allowed.
      
       [ bp: Space it out to make it more visible. ]
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarRik van Riel <riel@surriel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kvm ML <kvm@vger.kernel.org>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181128222035.2996-6-bigeasy@linutronix.deSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      028f17e0
    • Lubomir Rintel's avatar
      ARM: dts: mmp2: fix TWSI2 · 75086100
      Lubomir Rintel authored
      [ Upstream commit 1147e05ac9fc2ef86a3691e7ca5c2db7602d81dd ]
      
      Marvell keeps their MMP2 datasheet secret, but there are good clues
      that TWSI2 is not on 0xd4025000 on that platform, not does it use
      IRQ 58. In fact, the IRQ 58 on MMP2 seems to be a signal processor:
      
         arch/arm/mach-mmp/irqs.h:#define IRQ_MMP2_MSP  58
      
      I'm taking a somewhat educated guess that is probably a copy & paste
      error from PXA168 or PXA910 and that the real controller in fact hides
      at address 0xd4031000 and uses an interrupt line multiplexed via IRQ 17.
      
      I'm also copying some properties from TWSI1 that were missing or
      incorrect.
      
      Tested on a OLPC XO 1.75 machine, where the RTC is on TWSI2.
      Signed-off-by: default avatarLubomir Rintel <lkundrak@v3.sk>
      Tested-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      75086100
    • Mark Rutland's avatar
      arm64: ftrace: don't adjust the LR value · 2d6f9a86
      Mark Rutland authored
      [ Upstream commit 6e803e2e6e367db9a0d6ecae1bd24bb5752011bd ]
      
      The core ftrace code requires that when it is handed the PC of an
      instrumented function, this PC is the address of the instrumented
      instruction. This is necessary so that the core ftrace code can identify
      the specific instrumentation site. Since the instrumented function will
      be a BL, the address of the instrumented function is LR - 4 at entry to
      the ftrace code.
      
      This fixup is applied in the mcount_get_pc and mcount_get_pc0 helpers,
      which acquire the PC of the instrumented function.
      
      The mcount_get_lr helper is used to acquire the LR of the instrumented
      function, whose value does not require this adjustment, and cannot be
      adjusted to anything meaningful. No adjustment of this value is made on
      other architectures, including arm. However, arm64 adjusts this value by
      4.
      
      This patch brings arm64 in line with other architectures and removes the
      adjustment of the LR value.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Torsten Duwe <duwe@suse.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2d6f9a86
    • Nathan Chancellor's avatar
      ARM: OMAP2+: hwmod: Fix some section annotations · c34330e1
      Nathan Chancellor authored
      [ Upstream commit c10b26abeb53cabc1e6271a167d3f3d396ce0218 ]
      
      When building the kernel with Clang, the following section mismatch
      warnings appears:
      
      WARNING: vmlinux.o(.text+0x2d398): Section mismatch in reference from
      the function _setup() to the function .init.text:_setup_iclk_autoidle()
      The function _setup() references
      the function __init _setup_iclk_autoidle().
      This is often because _setup lacks a __init
      annotation or the annotation of _setup_iclk_autoidle is wrong.
      
      WARNING: vmlinux.o(.text+0x2d3a0): Section mismatch in reference from
      the function _setup() to the function .init.text:_setup_reset()
      The function _setup() references
      the function __init _setup_reset().
      This is often because _setup lacks a __init
      annotation or the annotation of _setup_reset is wrong.
      
      WARNING: vmlinux.o(.text+0x2d408): Section mismatch in reference from
      the function _setup() to the function .init.text:_setup_postsetup()
      The function _setup() references
      the function __init _setup_postsetup().
      This is often because _setup lacks a __init
      annotation or the annotation of _setup_postsetup is wrong.
      
      _setup is used in omap_hwmod_allocate_module, which isn't marked __init
      and looks like it shouldn't be, meaning to fix these warnings, those
      functions must be moved out of the init section, which this patch does.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c34330e1
    • Frank Rowand's avatar
      powerpc/pseries: add of_node_put() in dlpar_detach_node() · c9ddfda6
      Frank Rowand authored
      [ Upstream commit 5b3f5c408d8cc59b87e47f1ab9803dbd006e4a91 ]
      
      The previous commit, "of: overlay: add missing of_node_get() in
      __of_attach_node_sysfs" added a missing of_node_get() to
      __of_attach_node_sysfs().  This results in a refcount imbalance
      for nodes attached with dlpar_attach_node().  The calling sequence
      from dlpar_attach_node() to __of_attach_node_sysfs() is:
      
         dlpar_attach_node()
            of_attach_node()
               __of_attach_node_sysfs()
      
      For more detailed description of the node refcount, see
      commit 68baf692 ("powerpc/pseries: Fix of_node_put() underflow
      during DLPAR remove").
      Tested-by: default avatarAlan Tull <atull@kernel.org>
      Acked-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarFrank Rowand <frank.rowand@sony.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c9ddfda6
    • Colin Ian King's avatar
      x86/PCI: Fix Broadcom CNB20LE unintended sign extension (redux) · 2f85daf8
      Colin Ian King authored
      [ Upstream commit 53bb565fc5439f2c8c57a786feea5946804aa3e9 ]
      
      In the expression "word1 << 16", word1 starts as u16, but is promoted to a
      signed int, then sign-extended to resource_size_t, which is probably not
      what was intended.  Cast to resource_size_t to avoid the sign extension.
      
      This fixes an identical issue as fixed by commit 0b2d7076 ("x86/PCI:
      Fix Broadcom CNB20LE unintended sign extension") back in 2014.
      
      Detected by CoverityScan, CID#138749, 138750 ("Unintended sign extension")
      
      Fixes: 3f6ea84a ("PCI: read memory ranges out of Broadcom CNB20LE host bridge")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarBjorn Helgaas <helgaas@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      2f85daf8
    • Yufen Wang's avatar
      ARM: 8808/1: kexec:offline panic_smp_self_stop CPU · aeef84f3
      Yufen Wang authored
      [ Upstream commit 82c08c3e7f171aa7f579b231d0abbc1d62e91974 ]
      
      In case panic() and panic() called at the same time on different CPUS.
      For example:
      CPU 0:
        panic()
           __crash_kexec
             machine_crash_shutdown
               crash_smp_send_stop
             machine_kexec
               BUG_ON(num_online_cpus() > 1);
      
      CPU 1:
        panic()
          local_irq_disable
          panic_smp_self_stop
      
      If CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop(), kdump
      fails. CPU1 can't receive the ipi irq, CPU1 will be always online.
      To fix this problem, this patch split out the panic_smp_self_stop()
      and add set_cpu_online(smp_processor_id(), false).
      Signed-off-by: default avatarYufen Wang <wangyufen@huawei.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      aeef84f3
  4. 06 Feb, 2019 5 commits
    • James Morse's avatar
      arm64: hyp-stub: Forbid kprobing of the hyp-stub · 7685bb0e
      James Morse authored
      commit 8fac5cbdfe0f01254d9d265c6aa1a95f94f58595 upstream.
      
      The hyp-stub is loaded by the kernel's early startup code at EL2
      during boot, before KVM takes ownership later. The hyp-stub's
      text is part of the regular kernel text, meaning it can be kprobed.
      
      A breakpoint in the hyp-stub causes the CPU to spin in el2_sync_invalid.
      
      Add it to the __hyp_text.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7685bb0e
    • Koen Vandeputte's avatar
      ARM: cns3xxx: Fix writing to wrong PCI config registers after alignment · 1472585f
      Koen Vandeputte authored
      commit 65dbb423cf28232fed1732b779249d6164c5999b upstream.
      
      Originally, cns3xxx used its own functions for mapping, reading and
      writing config registers.
      
      Commit 802b7c06 ("ARM: cns3xxx: Convert PCI to use generic config
      accessors") removed the internal PCI config write function in favor of
      the generic one:
      
        cns3xxx_pci_write_config() --> pci_generic_config_write()
      
      cns3xxx_pci_write_config() expected aligned addresses, being produced by
      cns3xxx_pci_map_bus() while the generic one pci_generic_config_write()
      actually expects the real address as both the function and hardware are
      capable of byte-aligned writes.
      
      This currently leads to pci_generic_config_write() writing to the wrong
      registers.
      
      For instance, upon ath9k module loading:
      
      - driver ath9k gets loaded
      - The driver wants to write value 0xA8 to register PCI_LATENCY_TIMER,
        located at 0x0D
      - cns3xxx_pci_map_bus() aligns the address to 0x0C
      - pci_generic_config_write() effectively writes 0xA8 into register 0x0C
        (CACHE_LINE_SIZE)
      
      Fix the bug by removing the alignment in the cns3xxx mapping function.
      
      Fixes: 802b7c06 ("ARM: cns3xxx: Convert PCI to use generic config accessors")
      Signed-off-by: default avatarKoen Vandeputte <koen.vandeputte@ncentric.com>
      [lorenzo.pieralisi@arm.com: updated commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Acked-by: default avatarKrzysztof Halasa <khalasa@piap.pl>
      Acked-by: default avatarTim Harvey <tharvey@gateworks.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      CC: stable@vger.kernel.org	# v4.0+
      CC: Bjorn Helgaas <bhelgaas@google.com>
      CC: Olof Johansson <olof@lixom.net>
      CC: Robin Leblon <robin.leblon@ncentric.com>
      CC: Rob Herring <robh@kernel.org>
      CC: Russell King <linux@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1472585f
    • David Hildenbrand's avatar
      s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU · dda20175
      David Hildenbrand authored
      commit 60f1bf29c0b2519989927cae640cd1f50f59dc7f upstream.
      
      When calling smp_call_ipl_cpu() from the IPL CPU, we will try to read
      from pcpu_devices->lowcore. However, due to prefixing, that will result
      in reading from absolute address 0 on that CPU. We have to go via the
      actual lowcore instead.
      
      This means that right now, we will read lc->nodat_stack == 0 and
      therfore work on a very wrong stack.
      
      This BUG essentially broke rebooting under QEMU TCG (which will report
      a low address protection exception). And checking under KVM, it is
      also broken under KVM. With 1 VCPU it can be easily triggered.
      
      :/# echo 1 > /proc/sys/kernel/sysrq
      :/# echo b > /proc/sysrq-trigger
      [   28.476745] sysrq: SysRq : Resetting
      [   28.476793] Kernel stack overflow.
      [   28.476817] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13
      [   28.476820] Hardware name: IBM 2964 NE1 716 (KVM/Linux)
      [   28.476826] Krnl PSW : 0400c00180000000 0000000000115c0c (pcpu_delegate+0x12c/0x140)
      [   28.476861]            R:0 T:1 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
      [   28.476863] Krnl GPRS: ffffffffffffffff 0000000000000000 000000000010dff8 0000000000000000
      [   28.476864]            0000000000000000 0000000000000000 0000000000ab7090 000003e0006efbf0
      [   28.476864]            000000000010dff8 0000000000000000 0000000000000000 0000000000000000
      [   28.476865]            000000007fffc000 0000000000730408 000003e0006efc58 0000000000000000
      [   28.476887] Krnl Code: 0000000000115bfe: 4170f000            la      %r7,0(%r15)
      [   28.476887]            0000000000115c02: 41f0a000            la      %r15,0(%r10)
      [   28.476887]           #0000000000115c06: e370f0980024        stg     %r7,152(%r15)
      [   28.476887]           >0000000000115c0c: c0e5fffff86e        brasl   %r14,114ce8
      [   28.476887]            0000000000115c12: 41f07000            la      %r15,0(%r7)
      [   28.476887]            0000000000115c16: a7f4ffa8            brc     15,115b66
      [   28.476887]            0000000000115c1a: 0707                bcr     0,%r7
      [   28.476887]            0000000000115c1c: 0707                bcr     0,%r7
      [   28.476901] Call Trace:
      [   28.476902] Last Breaking-Event-Address:
      [   28.476920]  [<0000000000a01c4a>] arch_call_rest_init+0x22/0x80
      [   28.476927] Kernel panic - not syncing: Corrupt kernel stack, can't continue.
      [   28.476930] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13
      [   28.476932] Hardware name: IBM 2964 NE1 716 (KVM/Linux)
      [   28.476932] Call Trace:
      
      Fixes: 2f859d0d ("s390/smp: reduce size of struct pcpu")
      Cc: stable@vger.kernel.org # 4.0+
      Reported-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dda20175
    • Shaokun Zhang's avatar
      arm64: mm: remove page_mapping check in __sync_icache_dcache · 029b5be5
      Shaokun Zhang authored
      commit 20c27a42 upstream.
      
      __sync_icache_dcache unconditionally skips the cache maintenance for
      anonymous pages, under the assumption that flushing is only required in
      the presence of D-side aliases [see 7249b79f ("arm64: Do not flush
      the D-cache for anonymous pages")].
      
      Unfortunately, this breaks migration of anonymous pages holding
      self-modifying code, where userspace cannot be reasonably expected to
      reissue maintenance instructions in response to a migration.
      
      This patch fixes the problem by removing the broken page_mapping(page)
      check from the cache syncing code, otherwise we may end up fetching and
      executing stale instructions from the PoU.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarShaokun Zhang <zhangshaokun@hisilicon.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Cc: Amanieu d'Antras <amanieu@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      029b5be5
    • Daniel Drake's avatar
      x86/kaslr: Fix incorrect i8254 outb() parameters · 5efadf3b
      Daniel Drake authored
      commit 7e6fc2f50a3197d0e82d1c0e86282976c9e6c8a4 upstream.
      
      The outb() function takes parameters value and port, in that order.  Fix
      the parameters used in the kalsr i8254 fallback code.
      
      Fixes: 5bfce5ef ("x86, kaslr: Provide randomness functions")
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: hpa@zytor.com
      Cc: linux@endlessm.com
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190107034024.15005-1-drake@endlessm.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5efadf3b