1. 07 Aug, 2017 14 commits
    • Cheah Kok Cheong's avatar
      Staging: comedi: comedi_fops: Avoid orphaned proc entry · b5a48676
      Cheah Kok Cheong authored
      commit bf279ece upstream.
      
      Move comedi_proc_init to the end to avoid orphaned proc entry
      if module loading failed.
      Signed-off-by: default avatarCheah Kok Cheong <thrust73@gmail.com>
      Reviewed-by: default avatarIan Abbott <abbotti@mev.co.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5a48676
    • Greg Kroah-Hartman's avatar
      Revert "powerpc/numa: Fix percpu allocations to be NUMA aware" · 0c335d55
      Greg Kroah-Hartman authored
      This reverts commit 8c92870b which is
      commit ba4a648f upstream.
      
      Michal Hocko writes:
      
      JFYI. We have encountered a regression after applying this patch on a
      large ppc machine. While the patch is the right thing to do it doesn't
      work well with the current vmalloc area size on ppc and large machines
      where NUMA nodes are very far from each other. Just for the reference
      the boot fails on such a machine with bunch of warning preceeding it.
      See http://lkml.kernel.org/r/20170724134240.GL25221@dhcp22.suse.cz
      
      It seems the right thing to do is to enlarge the vmalloc space on ppc
      but this is not the case in the upstream kernel yet AFAIK. It is also
      questionable whether that is a stable material but I will decision on
      you here.
      
      We have reverted this patch from our 4.4 based kernel.
      
      Newer kernels do not have enlarged vmalloc space yet AFAIK so they won't
      work properly eiter. This bug is quite rare though because you need a
      specific HW configuration to trigger the issue - namely NUMA nodes have
      to be far away from each other in the physical memory space.
      
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c335d55
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Save/restore host values of debug registers · fcd35f5a
      Paul Mackerras authored
      commit 7ceaa6dc upstream.
      
      At present, HV KVM on POWER8 and POWER9 machines loses any instruction
      or data breakpoint set in the host whenever a guest is run.
      Instruction breakpoints are currently only used by xmon, but ptrace
      and the perf_event subsystem can set data breakpoints as well as xmon.
      
      To fix this, we save the host values of the debug registers (CIABR,
      DAWR and DAWRX) before entering the guest and restore them on exit.
      To provide space to save them in the stack frame, we expand the stack
      frame allocated by kvmppc_hv_entry() from 112 to 144 bytes.
      
      [paulus@ozlabs.org - Adjusted stack offsets since we aren't saving
       POWER9-specific registers.]
      
      Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcd35f5a
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Reload HTM registers explicitly · 17d38105
      Paul Mackerras authored
      Commit 46a704f8 ("KVM: PPC: Book3S HV: Preserve userspace HTM
      state properly", 2017-06-15) added code which assumes that the kernel
      is able to handle a TM (transactional memory) unavailable interrupt
      from userspace by reloading the TM-related registers and enabling TM
      for the process.  That ability was added in the 4.9 kernel; earlier
      kernel versions simply panic on getting the TM unavailable interrupt.
      
      Since commit 46a704f8 has been backported to the 4.4 stable tree
      as commit 824b9506, 4.4.75 and subsequent versions are vulnerable
      to a userspace-triggerable panic.
      
      This patch fixes the problem by explicitly reloading the TM-related
      registers before returning to userspace, rather than disabling TM
      for the process.
      
      Commit 46a704f8 also failed to enable TM for the kernel, leading
      to a TM unavailable interrupt in the kernel, causing an oops.  This
      fixes that problem too, by enabling TM before accessing the TM
      registers.  That problem is fixed upstream by the patch "KVM: PPC:
      Book3S HV: Enable TM before accessing TM registers".
      
      Fixes: 824b9506 ("KVM: PPC: Book3S HV: Preserve userspace HTM state properly")
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17d38105
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Restore critical SPRs to host values on guest exit · f5b29db2
      Paul Mackerras authored
      commit 4c3bb4cc upstream.
      
      This restores several special-purpose registers (SPRs) to sane values
      on guest exit that were missed before.
      
      TAR and VRSAVE are readable and writable by userspace, and we need to
      save and restore them to prevent the guest from potentially affecting
      userspace execution (not that TAR or VRSAVE are used by any known
      program that run uses the KVM_RUN ioctl).  We save/restore these
      in kvmppc_vcpu_run_hv() rather than on every guest entry/exit.
      
      FSCR affects userspace execution in that it can prohibit access to
      certain facilities by userspace.  We restore it to the normal value
      for the task on exit from the KVM_RUN ioctl.
      
      IAMR is normally 0, and is restored to 0 on guest exit.  However,
      with a radix host on POWER9, it is set to a value that prevents the
      kernel from executing user-accessible memory.  On POWER9, we save
      IAMR on guest entry and restore it on guest exit to the saved value
      rather than 0.  On POWER8 we continue to set it to 0 on guest exit.
      
      PSPB is normally 0.  We restore it to 0 on guest exit to prevent
      userspace taking advantage of the guest having set it non-zero
      (which would allow userspace to set its SMT priority to high).
      
      UAMOR is normally 0.  We restore it to 0 on guest exit to prevent
      the AMR from being used as a covert channel between userspace
      processes, since the AMR is not context-switched at present.
      
      [paulus@ozlabs.org - removed IAMR bits that are only needed on POWER9;
       adjusted FSCR save/restore for lack of fscr field in thread_struct.]
      
      Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f5b29db2
    • Paul Mackerras's avatar
      KVM: PPC: Book3S HV: Context-switch EBB registers properly · 339fa4af
      Paul Mackerras authored
      commit ca8efa1d upstream.
      
      This adds code to save the values of three SPRs (special-purpose
      registers) used by userspace to control event-based branches (EBBs),
      which are essentially interrupts that get delivered directly to
      userspace.  These registers are loaded up with guest values when
      entering the guest, and their values are saved when exiting the
      guest, but we were not saving the host values and restoring them
      before going back to userspace.
      
      On POWER8 this would only affect userspace programs which explicitly
      request the use of EBBs and also use the KVM_RUN ioctl, since the
      only source of EBBs on POWER8 is the PMU, and there is an explicit
      enable bit in the PMU registers (and those PMU registers do get
      properly context-switched between host and guest).  On POWER9 there
      is provision for externally-generated EBBs, and these are not subject
      to the control in the PMU registers.
      
      Since these registers only affect userspace, we can save them when
      we first come in from userspace and restore them before returning to
      userspace, rather than saving/restoring the host values on every
      guest entry/exit.  Similarly, we don't need to worry about their
      values on offline secondary threads since they execute in the context
      of the idle task, which never executes in userspace.
      
      Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      339fa4af
    • Ben Skeggs's avatar
      drm/nouveau/bar/gf100: fix access to upper half of BAR2 · 29da136f
      Ben Skeggs authored
      commit 38bcb208 upstream.
      
      Bit 30 being set causes the upper half of BAR2 to stay in physical mode,
      mapped over the end of VRAM, even when the rest of the BAR has been set
      to virtual mode.
      
      We inherited our initial value from RM, but I'm not aware of any reason
      we need to keep it that way.
      
      This fixes severe GPU hang/lockup issues revealed by Wayland on F26.
      
      Shout-out to NVIDIA for the quick response with the potential cause!
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29da136f
    • Sinclair Yeh's avatar
      drm/vmwgfx: Fix gcc-7.1.1 warning · fde885f1
      Sinclair Yeh authored
      commit fcfffdd8 upstream.
      
      The current code does not look correct, and the reason for it is
      probably lost.  Since this now generates a compiler warning,
      fix it to what makes sense.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSinclair Yeh <syeh@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fde885f1
    • Ofer Heifetz's avatar
      md/raid5: add thread_group worker async_tx_issue_pending_all · 376830c3
      Ofer Heifetz authored
      commit 7e96d559 upstream.
      
      Since thread_group worker and raid5d kthread are not in sync, if
      worker writes stripe before raid5d then requests will be waiting
      for issue_pendig.
      
      Issue observed when building raid5 with ext4, in some build runs
      jbd2 would get hung and requests were waiting in the HW engine
      waiting to be issued.
      
      Fix this by adding a call to async_tx_issue_pending_all in the
      raid5_do_work.
      Signed-off-by: default avatarOfer Heifetz <oferh@marvell.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      376830c3
    • Herbert Xu's avatar
      crypto: authencesn - Fix digest_null crash · 2148e9ab
      Herbert Xu authored
      commit 41cdf7a4 upstream.
      
      When authencesn is used together with digest_null a crash will
      occur on the decrypt path.  This is because normally we perform
      a special setup to preserve the ESN, but this is skipped if there
      is no authentication.  However, on the post-authentication path
      it always expects the preservation to be in place, thus causing
      a crash when digest_null is used.
      
      This patch fixes this by also skipping the post-processing when
      there is no authentication.
      
      Fixes: 104880a6 ("crypto: authencesn - Convert to new AEAD...")
      Reported-by: default avatarJan Tluka <jtluka@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2148e9ab
    • Laurent Vivier's avatar
      powerpc/pseries: Fix of_node_put() underflow during reconfig remove · c4efb743
      Laurent Vivier authored
      commit 4fd1bd44 upstream.
      
      As for commit 68baf692 ("powerpc/pseries: Fix of_node_put()
      underflow during DLPAR remove"), the call to of_node_put() must be
      removed from pSeries_reconfig_remove_node().
      
      dlpar_detach_node() and pSeries_reconfig_remove_node() both call
      of_detach_node(), and thus the node should not be released in both
      cases.
      
      Fixes: 0829f6d1 ("of: device_node kobject lifecycle fixes")
      Signed-off-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4efb743
    • Eric Dumazet's avatar
      net: reduce skb_warn_bad_offload() noise · fdbcb81b
      Eric Dumazet authored
      commit b2504a5d upstream.
      
      Dmitry reported warnings occurring in __skb_gso_segment() [1]
      
      All SKB_GSO_DODGY producers can allow user space to feed
      packets that trigger the current check.
      
      We could prevent them from doing so, rejecting packets, but
      this might add regressions to existing programs.
      
      It turns out our SKB_GSO_DODGY handlers properly set up checksum
      information that is needed anyway when packets needs to be segmented.
      
      By checking again skb_needs_check() after skb_mac_gso_segment(),
      we should remove these pesky warnings, at a very minor cost.
      
      With help from Willem de Bruijn
      
      [1]
      WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
      lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
       ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
       ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
       ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
      Call Trace:
       [<ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline]
       [<ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
       [<ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179
       [<ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542
       [<ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
       [<ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
       [<ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
       [<ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline]
       [<ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
       [<ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
       [<ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
       [<ffffffff83ad161d>] packet_snd net/packet/af_packet.c:2930 [inline]
       [<ffffffff83ad161d>] packet_sendmsg+0x32ed/0x4d30 net/packet/af_packet.c:2955
       [<ffffffff834f0aaa>] sock_sendmsg_nosec net/socket.c:621 [inline]
       [<ffffffff834f0aaa>] sock_sendmsg+0xca/0x110 net/socket.c:631
       [<ffffffff834f329a>] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1954
       [<ffffffff834f5e58>] __sys_sendmsg+0x138/0x300 net/socket.c:1988
       [<ffffffff834f604d>] SYSC_sendmsg net/socket.c:1999 [inline]
       [<ffffffff834f604d>] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
       [<ffffffff84371941>] entry_SYSCALL_64_fastpath+0x1f/0xc2
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov  <dvyukov@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Mark Salyzyn <salyzyn@android.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdbcb81b
    • Joel Fernandes's avatar
      pstore: Make spinlock per zone instead of global · 08408f7a
      Joel Fernandes authored
      commit 10970449 upstream.
      
      Currently pstore has a global spinlock for all zones. Since the zones
      are independent and modify different areas of memory, there's no need
      to have a global lock, so we should use a per-zone lock as introduced
      here. Also, when ramoops's ftrace use-case has a FTRACE_PER_CPU flag
      introduced later, which splits the ftrace memory area into a single zone
      per CPU, it will eliminate the need for locking. In preparation for this,
      make the locking optional.
      Signed-off-by: default avatarJoel Fernandes <joelaf@google.com>
      [kees: updated commit message]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Leo Yan <leo.yan@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08408f7a
    • Yuejie Shi's avatar
      af_key: Add lock to key dump · b627f600
      Yuejie Shi authored
      commit 89e357d8 upstream.
      
      A dump may come in the middle of another dump, modifying its dump
      structure members. This race condition will result in NULL pointer
      dereference in kernel. So add a lock to prevent that race.
      
      Fixes: 83321d6b ("[AF_KEY]: Dump SA/SP entries non-atomically")
      Signed-off-by: default avatarYuejie Shi <syjcnss@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarMark Salyzyn <salyzyn@android.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b627f600
  2. 27 Jul, 2017 26 commits