1. 11 Aug, 2017 5 commits
    • Ofer Heifetz's avatar
      md/raid5: add thread_group worker async_tx_issue_pending_all · c81489cc
      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>
      c81489cc
    • Laurent Vivier's avatar
      powerpc/pseries: Fix of_node_put() underflow during reconfig remove · 716c82ac
      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>
      716c82ac
    • Eric Dumazet's avatar
      net: reduce skb_warn_bad_offload() noise · d85f4de8
      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>
      d85f4de8
    • Joel Fernandes's avatar
      pstore: Make spinlock per zone instead of global · 2d0abb7b
      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>
      2d0abb7b
    • Yuejie Shi's avatar
      af_key: Add lock to key dump · c64a196b
      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>
      c64a196b
  2. 27 Jul, 2017 35 commits