1. 10 Dec, 2016 12 commits
    • Herbert Xu's avatar
      netlink: Do not schedule work from sk_destruct · baaf0c65
      Herbert Xu authored
      [ Upstream commit ed5d7788 ]
      
      It is wrong to schedule a work from sk_destruct using the socket
      as the memory reserve because the socket will be freed immediately
      after the return from sk_destruct.
      
      Instead we should do the deferral prior to sk_free.
      
      This patch does just that.
      
      Fixes: 707693c8 ("netlink: Call cb->done from a worker thread")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      baaf0c65
    • Herbert Xu's avatar
      netlink: Call cb->done from a worker thread · d1ed9c1d
      Herbert Xu authored
      [ Upstream commit 707693c8 ]
      
      The cb->done interface expects to be called in process context.
      This was broken by the netlink RCU conversion.  This patch fixes
      it by adding a worker struct to make the cb->done call where
      necessary.
      
      Fixes: 21e4902a ("netlink: Lockless lookup with RCU grace...")
      Reported-by: default avatarSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1ed9c1d
    • Amir Vadai's avatar
      net/sched: pedit: make sure that offset is valid · 6c42bd6a
      Amir Vadai authored
      [ Upstream commit 95c2027b ]
      
      Add a validation function to make sure offset is valid:
      1. Not below skb head (could happen when offset is negative).
      2. Validate both 'offset' and 'at'.
      Signed-off-by: default avatarAmir Vadai <amir@vadai.me>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c42bd6a
    • Daniel Borkmann's avatar
      net, sched: respect rcu grace period on cls destruction · cfa7c16d
      Daniel Borkmann authored
      [ Upstream commit d9363774 ]
      
      Roi reported a crash in flower where tp->root was NULL in ->classify()
      callbacks. Reason is that in ->destroy() tp->root is set to NULL via
      RCU_INIT_POINTER(). It's problematic for some of the classifiers, because
      this doesn't respect RCU grace period for them, and as a result, still
      outstanding readers from tc_classify() will try to blindly dereference
      a NULL tp->root.
      
      The tp->root object is strictly private to the classifier implementation
      and holds internal data the core such as tc_ctl_tfilter() doesn't know
      about. Within some classifiers, such as cls_bpf, cls_basic, etc, tp->root
      is only checked for NULL in ->get() callback, but nowhere else. This is
      misleading and seemed to be copied from old classifier code that was not
      cleaned up properly. For example, d3fa76ee ("[NET_SCHED]: cls_basic:
      fix NULL pointer dereference") moved tp->root initialization into ->init()
      routine, where before it was part of ->change(), so ->get() had to deal
      with tp->root being NULL back then, so that was indeed a valid case, after
      d3fa76ee, not really anymore. We used to set tp->root to NULL long
      ago in ->destroy(), see 47a1a1d4 ("pkt_sched: remove unnecessary xchg()
      in packet classifiers"); but the NULLifying was reintroduced with the
      RCUification, but it's not correct for every classifier implementation.
      
      In the cases that are fixed here with one exception of cls_cgroup, tp->root
      object is allocated and initialized inside ->init() callback, which is always
      performed at a point in time after we allocate a new tp, which means tp and
      thus tp->root was not globally visible in the tp chain yet (see tc_ctl_tfilter()).
      Also, on destruction tp->root is strictly kfree_rcu()'ed in ->destroy()
      handler, same for the tp which is kfree_rcu()'ed right when we return
      from ->destroy() in tcf_destroy(). This means, the head object's lifetime
      for such classifiers is always tied to the tp lifetime. The RCU callback
      invocation for the two kfree_rcu() could be out of order, but that's fine
      since both are independent.
      
      Dropping the RCU_INIT_POINTER(tp->root, NULL) for these classifiers here
      means that 1) we don't need a useless NULL check in fast-path and, 2) that
      outstanding readers of that tp in tc_classify() can still execute under
      respect with RCU grace period as it is actually expected.
      
      Things that haven't been touched here: cls_fw and cls_route. They each
      handle tp->root being NULL in ->classify() path for historic reasons, so
      their ->destroy() implementation can stay as is. If someone actually
      cares, they could get cleaned up at some point to avoid the test in fast
      path. cls_u32 doesn't set tp->root to NULL. For cls_rsvp, I just added a
      !head should anyone actually be using/testing it, so it at least aligns with
      cls_fw and cls_route. For cls_flower we additionally need to defer rhashtable
      destruction (to a sleepable context) after RCU grace period as concurrent
      readers might still access it. (Note that in this case we need to hold module
      reference to keep work callback address intact, since we only wait on module
      unload for all call_rcu()s to finish.)
      
      This fixes one race to bring RCU grace period guarantees back. Next step
      as worked on by Cong however is to fix 1e052be6 ("net_sched: destroy
      proto tp when all filters are gone") to get the order of unlinking the tp
      in tc_ctl_tfilter() for the RTM_DELTFILTER case right by moving
      RCU_INIT_POINTER() before tcf_destroy() and let the notification for
      removal be done through the prior ->delete() callback. Both are independant
      issues. Once we have that right, we can then clean tp->root up for a number
      of classifiers by not making them RCU pointers, which requires a new callback
      (->uninit) that is triggered from tp's RCU callback, where we just kfree()
      tp->root from there.
      
      Fixes: 1f947bf1 ("net: sched: rcu'ify cls_bpf")
      Fixes: 9888faef ("net: sched: cls_basic use RCU")
      Fixes: 70da9f0b ("net: sched: cls_flow use RCU")
      Fixes: 77b9900e ("tc: introduce Flower classifier")
      Fixes: bf3994d2 ("net/sched: introduce Match-all classifier")
      Fixes: 952313bd ("net: sched: cls_cgroup use RCU")
      Reported-by: default avatarRoi Dayan <roid@mellanox.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Roi Dayan <roid@mellanox.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Acked-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfa7c16d
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: Ensure we re-negotiate EEE during after link change · 94de6f2f
      Florian Fainelli authored
      [ Upstream commit 76da8706 ]
      
      In case the link change and EEE is enabled or disabled, always try to
      re-negotiate this with the link partner.
      
      Fixes: 450b05c1 ("net: dsa: bcm_sf2: add support for controlling EEE")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      94de6f2f
    • Guillaume Nault's avatar
      l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind() · 56366fa0
      Guillaume Nault authored
      [ Upstream commit 32c23116 ]
      
      Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind().
      Without lock, a concurrent call could modify the socket flags between
      the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way,
      a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it
      would then leave a stale pointer there, generating use-after-free
      errors when walking through the list or modifying adjacent entries.
      
      BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8
      Write of size 8 by task syz-executor/10987
      CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
       ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0
       ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc
       ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0
      Call Trace:
       [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15
       [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
       [<     inline     >] print_address_description mm/kasan/report.c:194
       [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283
       [<     inline     >] kasan_report mm/kasan/report.c:303
       [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329
       [<     inline     >] __write_once_size ./include/linux/compiler.h:249
       [<     inline     >] __hlist_del ./include/linux/list.h:622
       [<     inline     >] hlist_del_init ./include/linux/list.h:637
       [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239
       [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
       [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
       [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
       [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
       [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
       [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
       [<ffffffff813774f9>] task_work_run+0xf9/0x170
       [<ffffffff81324aae>] do_exit+0x85e/0x2a00
       [<ffffffff81326dc8>] do_group_exit+0x108/0x330
       [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
       [<ffffffff811b49af>] do_signal+0x7f/0x18f0
       [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
       [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
       [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
       [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
      Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448
      Allocated:
      PID = 10987
       [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
       [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
       [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0
       [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20
       [ 1116.897025] [<     inline     >] slab_post_alloc_hook mm/slab.h:417
       [ 1116.897025] [<     inline     >] slab_alloc_node mm/slub.c:2708
       [ 1116.897025] [<     inline     >] slab_alloc mm/slub.c:2716
       [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721
       [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326
       [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388
       [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182
       [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153
       [ 1116.897025] [<     inline     >] sock_create net/socket.c:1193
       [ 1116.897025] [<     inline     >] SYSC_socket net/socket.c:1223
       [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203
       [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6
      Freed:
      PID = 10987
       [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20
       [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0
       [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0
       [ 1116.897025] [<     inline     >] slab_free_hook mm/slub.c:1352
       [ 1116.897025] [<     inline     >] slab_free_freelist_hook mm/slub.c:1374
       [ 1116.897025] [<     inline     >] slab_free mm/slub.c:2951
       [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973
       [ 1116.897025] [<     inline     >] sk_prot_free net/core/sock.c:1369
       [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444
       [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452
       [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460
       [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471
       [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589
       [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243
       [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415
       [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
       [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570
       [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017
       [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208
       [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244
       [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170
       [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00
       [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330
       [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307
       [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0
       [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156
       [ 1116.897025] [<     inline     >] prepare_exit_to_usermode arch/x86/entry/common.c:190
       [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259
       [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6
      Memory state around the buggy address:
       ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
                                                          ^
       ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      ==================================================================
      
      The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table.
      
      Fixes: c51ce497 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Tested-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56366fa0
    • Sabrina Dubroca's avatar
      rtnetlink: fix FDB size computation · aece024e
      Sabrina Dubroca authored
      [ Upstream commit f82ef3e1 ]
      
      Add missing NDA_VLAN attribute's size.
      
      Fixes: 1e53d5bb ("net: Pass VLAN ID to rtnl_fdb_notify.")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aece024e
    • WANG Cong's avatar
      af_unix: conditionally use freezable blocking calls in read · 6ef59b98
      WANG Cong authored
      [ Upstream commit 06a77b07 ]
      
      Commit 2b15af6f ("af_unix: use freezable blocking calls in read")
      converts schedule_timeout() to its freezable version, it was probably
      correct at that time, but later, commit 2b514574
      ("net: af_unix: implement splice for stream af_unix sockets") breaks
      the strong requirement for a freezable sleep, according to
      commit 0f9548ca:
      
          We shouldn't try_to_freeze if locks are held.  Holding a lock can cause a
          deadlock if the lock is later acquired in the suspend or hibernate path
          (e.g.  by dpm).  Holding a lock can also cause a deadlock in the case of
          cgroup_freezer if a lock is held inside a frozen cgroup that is later
          acquired by a process outside that group.
      
      The pipe_lock is still held at that point.
      
      So use freezable version only for the recvmsg call path, avoid impact for
      Android.
      
      Fixes: 2b514574 ("net: af_unix: implement splice for stream af_unix sockets")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Colin Cross <ccross@android.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ef59b98
    • Jeremy Linton's avatar
      net: sky2: Fix shutdown crash · acf9504a
      Jeremy Linton authored
      [ Upstream commit 06ba3b21 ]
      
      The sky2 frequently crashes during machine shutdown with:
      
      sky2_get_stats+0x60/0x3d8 [sky2]
      dev_get_stats+0x68/0xd8
      rtnl_fill_stats+0x54/0x140
      rtnl_fill_ifinfo+0x46c/0xc68
      rtmsg_ifinfo_build_skb+0x7c/0xf0
      rtmsg_ifinfo.part.22+0x3c/0x70
      rtmsg_ifinfo+0x50/0x5c
      netdev_state_change+0x4c/0x58
      linkwatch_do_dev+0x50/0x88
      __linkwatch_run_queue+0x104/0x1a4
      linkwatch_event+0x30/0x3c
      process_one_work+0x140/0x3e0
      worker_thread+0x60/0x44c
      kthread+0xdc/0xf0
      ret_from_fork+0x10/0x50
      
      This is caused by the sky2 being called after it has been shutdown.
      A previous thread about this can be found here:
      
      https://lkml.org/lkml/2016/4/12/410
      
      An alternative fix is to assure that IFF_UP gets cleared by
      calling dev_close() during shutdown. This is similar to what the
      bnx2/tg3/xgene and maybe others are doing to assure that the driver
      isn't being called following _shutdown().
      Signed-off-by: default avatarJeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      acf9504a
    • Paolo Abeni's avatar
      ip6_tunnel: disable caching when the traffic class is inherited · 49695d1e
      Paolo Abeni authored
      [ Upstream commit b5c2d495 ]
      
      If an ip6 tunnel is configured to inherit the traffic class from
      the inner header, the dst_cache must be disabled or it will foul
      the policy routing.
      
      The issue is apprently there since at leat Linux-2.6.12-rc2.
      Reported-by: default avatarLiam McBirnie <liam.mcbirnie@boeing.com>
      Cc: Liam McBirnie <liam.mcbirnie@boeing.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49695d1e
    • WANG Cong's avatar
      net: check dead netns for peernet2id_alloc() · 2b54505c
      WANG Cong authored
      [ Upstream commit cfc44a4d ]
      
      Andrei reports we still allocate netns ID from idr after we destroy
      it in cleanup_net().
      
      cleanup_net():
        ...
        idr_destroy(&net->netns_ids);
        ...
        list_for_each_entry_reverse(ops, &pernet_list, list)
          ops_exit_list(ops, &net_exit_list);
            -> rollback_registered_many()
              -> rtmsg_ifinfo_build_skb()
               -> rtnl_fill_ifinfo()
                 -> peernet2id_alloc()
      
      After that point we should not even access net->netns_ids, we
      should check the death of the current netns as early as we can in
      peernet2id_alloc().
      
      For net-next we can consider to avoid sending rtmsg totally,
      it is a good optimization for netns teardown path.
      
      Fixes: 0c7aecd4 ("netns: add rtnl cmd to add and get peer netns ids")
      Reported-by: default avatarAndrei Vagin <avagin@gmail.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Acked-by: default avatarAndrei Vagin <avagin@openvz.org>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b54505c
    • Eric Dumazet's avatar
      virtio-net: add a missing synchronize_net() · 790fd11f
      Eric Dumazet authored
      [ Upstream commit 963abe5c ]
      
      It seems many drivers do not respect napi_hash_del() contract.
      
      When napi_hash_del() is used before netif_napi_del(), an RCU grace
      period is needed before freeing NAPI object.
      
      Fixes: 91815639 ("virtio-net: rx busy polling support")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      790fd11f
  2. 08 Dec, 2016 14 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.37 · e5f84c14
      Greg Kroah-Hartman authored
      e5f84c14
    • James Morse's avatar
      arm64: suspend: Reconfigure PSTATE after resume from idle · 71710cd3
      James Morse authored
      commit d0854412 upstream.
      
      The suspend/resume path in kernel/sleep.S, as used by cpu-idle, does not
      save/restore PSTATE. As a result of this cpufeatures that were detected
      and have bits in PSTATE get lost when we resume from idle.
      
      UAO gets set appropriately on the next context switch. PAN will be
      re-enabled next time we return from user-space, but on a preemptible
      kernel we may run work accessing user space before this point.
      
      Add code to re-enable theses two features in __cpu_suspend_exit().
      We re-use uao_thread_switch() passing current.
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      [Removed UAO hooks and commit-message references: this feature is not
       present in v4.4]
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71710cd3
    • James Morse's avatar
      arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call · d24207a0
      James Morse authored
      commit 7209c868 upstream.
      
      Commit 338d4f49 ("arm64: kernel: Add support for Privileged Access
      Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1.
      This means the PSTATE.PAN bit won't be set until the next return to the
      kernel from userspace. On a preemptible kernel we may schedule work that
      accesses userspace on a CPU before it has done this.
      
      Now that cpufeature enable() calls are scheduled via stop_machine(), we
      can set PSTATE.PAN from the cpu_enable_pan() call.
      
      Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated
      is not immediately discarded.
      Reported-by: default avatarTony Thompson <anthony.thompson@arm.com>
      Reported-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      [will: fixed typo in comment]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d24207a0
    • James Morse's avatar
      arm64: cpufeature: Schedule enable() calls instead of calling them via IPI · da643dc1
      James Morse authored
      commit 2a6dcb2b upstream.
      
      The enable() call for a cpufeature/errata is called using on_each_cpu().
      This issues a cross-call IPI to get the work done. Implicitly, this
      stashes the running PSTATE in SPSR when the CPU receives the IPI, and
      restores it when we return. This means an enable() call can never modify
      PSTATE.
      
      To allow PAN to do this, change the on_each_cpu() call to use
      stop_machine(). This schedules the work on each CPU which allows
      us to modify PSTATE.
      
      This involves changing the protype of all the enable() functions.
      
      enable_cpu_capabilities() is called during boot and enables the feature
      on all online CPUs. This path now uses stop_machine(). CPU features for
      hotplug'd CPUs are enabled by verify_local_cpu_features() which only
      acts on the local CPU, and can already modify the running PSTATE as it
      is called from secondary_start_kernel().
      Reported-by: default avatarTony Thompson <anthony.thompson@arm.com>
      Reported-by: default avatarVladimir Murzin <vladimir.murzin@arm.com>
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      [Removed enable() hunks for features/errata v4.4. doesn't have. Changed
       caps->enable arg in enable_cpu_capabilities()]
      Signed-off-by: default avatarJames Morse <james.morse@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da643dc1
    • Johan Hovold's avatar
      pwm: Fix device reference leak · 4fd108fa
      Johan Hovold authored
      commit 0e1614ac upstream.
      
      Make sure to drop the reference to the parent device taken by
      class_find_device() after "unexporting" any children when deregistering
      a PWM chip.
      
      Fixes: 0733424c ("pwm: Unexport children before chip removal")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4fd108fa
    • Brian Norris's avatar
      mwifiex: printk() overflow with 32-byte SSIDs · d7a2c259
      Brian Norris authored
      commit fcd2042e upstream.
      
      SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
      when we print them out.
      
      This can be easily noticed by connecting to a network with a 32-octet
      SSID:
      
      [ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to
      '0123456789abcdef0123456789abcdef <uninitialized mem>' bssid
      xx:xx:xx:xx:xx:xx
      
      Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Acked-by: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d7a2c259
    • Johannes Thumshirn's avatar
      PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX) · ac6e42d7
      Johannes Thumshirn authored
      commit e42010d8 upstream.
      
      Per PCIe spec r3.0, sec 2.3.1.1, the Read Completion Boundary (RCB)
      determines the naturally aligned address boundaries on which a Read Request
      may be serviced with multiple Completions:
      
        - For a Root Complex, RCB is 64 bytes or 128 bytes
          This value is reported in the Link Control Register
      
          Note: Bridges and Endpoints may implement a corresponding command bit
          which may be set by system software to indicate the RCB value for the
          Root Complex, allowing the Bridge/Endpoint to optimize its behavior
          when the Root Complex’s RCB is 128 bytes.
      
        - For all other system elements, RCB is 128 bytes
      
      Per sec 7.8.7, if a Root Port only supports a 64-byte RCB, the RCB of all
      downstream devices must be clear, indicating an RCB of 64 bytes.  If the
      Root Port supports a 128-byte RCB, we may optionally set the RCB of
      downstream devices so they know they can generate larger Completions.
      
      Some BIOSes supply an _HPX that tells us to set RCB, even though the Root
      Port doesn't have RCB set, which may lead to Malformed TLP errors if the
      Endpoint generates completions larger than the Root Port can handle.
      
      The IBM x3850 X6 with BIOS version -[A8E120CUS-1.30]- 08/22/2016 supplies
      such an _HPX and a Mellanox MT27500 ConnectX-3 device fails to initialize:
      
        mlx4_core 0000:41:00.0: command 0xfff timed out (go bit not cleared)
        mlx4_core 0000:41:00.0: device is going to be reset
        mlx4_core 0000:41:00.0: Failed to obtain HW semaphore, aborting
        mlx4_core 0000:41:00.0: Fail to reset HCA
        ------------[ cut here ]------------
        kernel BUG at drivers/net/ethernet/mellanox/mlx4/catas.c:193!
      
      After 6cd33649 ("PCI: Add pci_configure_device() during enumeration")
      and 7a1562d4 ("PCI: Apply _HPX Link Control settings to all devices
      with a link"), we apply _HPX settings to *all* devices, not just those
      hot-added after boot.
      
      Before 7a1562d4, we didn't touch the Mellanox RCB, and the device
      worked.  After 7a1562d4, we set its RCB to 128, and it failed.
      
      Set the RCB to 128 iff the Root Port supports a 128-byte RCB.  Otherwise,
      set RCB to 64 bytes.  This effectively ignores what _HPX tells us about
      RCB.
      
      Note that this change only affects _HPX handling.  If we have no _HPX, this
      does nothing with RCB.
      
      [bhelgaas: changelog, clear RCB if not set for Root Port]
      Fixes: 6cd33649 ("PCI: Add pci_configure_device() during enumeration")
      Fixes: 7a1562d4 ("PCI: Apply _HPX Link Control settings to all devices with a link")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=187781Tested-by: default avatarFrank Danapfel <fdanapfe@redhat.com>
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac6e42d7
    • Johannes Thumshirn's avatar
      PCI: Export pcie_find_root_port · 140ff0a3
      Johannes Thumshirn authored
      commit e784930b upstream.
      
      Export pcie_find_root_port() so we can use it outside of PCIe-AER error
      injection.
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      140ff0a3
    • Ding Tianhong's avatar
      rcu: Fix soft lockup for rcu_nocb_kthread · dfb704f9
      Ding Tianhong authored
      commit bedc1969 upstream.
      
      Carrying out the following steps results in a softlockup in the
      RCU callback-offload (rcuo) kthreads:
      
      1. Connect to ixgbevf, and set the speed to 10Gb/s.
      2. Use ifconfig to bring the nic up and down repeatedly.
      
      [  317.005148] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
      [  368.106005] BUG: soft lockup - CPU#1 stuck for 22s! [rcuos/1:15]
      [  368.106005] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [  368.106005] task: ffff88057dd8a220 ti: ffff88057dd9c000 task.ti: ffff88057dd9c000
      [  368.106005] RIP: 0010:[<ffffffff81579e04>]  [<ffffffff81579e04>] fib_table_lookup+0x14/0x390
      [  368.106005] RSP: 0018:ffff88061fc83ce8  EFLAGS: 00000286
      [  368.106005] RAX: 0000000000000001 RBX: 00000000020155c0 RCX: 0000000000000001
      [  368.106005] RDX: ffff88061fc83d50 RSI: ffff88061fc83d70 RDI: ffff880036d11a00
      [  368.106005] RBP: ffff88061fc83d08 R08: 0000000000000001 R09: 0000000000000000
      [  368.106005] R10: ffff880036d11a00 R11: ffffffff819e0900 R12: ffff88061fc83c58
      [  368.106005] R13: ffffffff816154dd R14: ffff88061fc83d08 R15: 00000000020155c0
      [  368.106005] FS:  0000000000000000(0000) GS:ffff88061fc80000(0000) knlGS:0000000000000000
      [  368.106005] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  368.106005] CR2: 00007f8c2aee9c40 CR3: 000000057b222000 CR4: 00000000000407e0
      [  368.106005] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  368.106005] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [  368.106005] Stack:
      [  368.106005]  00000000010000c0 ffff88057b766000 ffff8802e380b000 ffff88057af03e00
      [  368.106005]  ffff88061fc83dc0 ffffffff815349a6 ffff88061fc83d40 ffffffff814ee146
      [  368.106005]  ffff8802e380af00 00000000e380af00 ffffffff819e0900 020155c0010000c0
      [  368.106005] Call Trace:
      [  368.106005]  <IRQ>
      [  368.106005]
      [  368.106005]  [<ffffffff815349a6>] ip_route_input_noref+0x516/0xbd0
      [  368.106005]  [<ffffffff814ee146>] ? skb_release_data+0xd6/0x110
      [  368.106005]  [<ffffffff814ee20a>] ? kfree_skb+0x3a/0xa0
      [  368.106005]  [<ffffffff8153698f>] ip_rcv_finish+0x29f/0x350
      [  368.106005]  [<ffffffff81537034>] ip_rcv+0x234/0x380
      [  368.106005]  [<ffffffff814fd656>] __netif_receive_skb_core+0x676/0x870
      [  368.106005]  [<ffffffff814fd868>] __netif_receive_skb+0x18/0x60
      [  368.106005]  [<ffffffff814fe4de>] process_backlog+0xae/0x180
      [  368.106005]  [<ffffffff814fdcb2>] net_rx_action+0x152/0x240
      [  368.106005]  [<ffffffff81077b3f>] __do_softirq+0xef/0x280
      [  368.106005]  [<ffffffff8161619c>] call_softirq+0x1c/0x30
      [  368.106005]  <EOI>
      [  368.106005]
      [  368.106005]  [<ffffffff81015d95>] do_softirq+0x65/0xa0
      [  368.106005]  [<ffffffff81077174>] local_bh_enable+0x94/0xa0
      [  368.106005]  [<ffffffff81114922>] rcu_nocb_kthread+0x232/0x370
      [  368.106005]  [<ffffffff81098250>] ? wake_up_bit+0x30/0x30
      [  368.106005]  [<ffffffff811146f0>] ? rcu_start_gp+0x40/0x40
      [  368.106005]  [<ffffffff8109728f>] kthread+0xcf/0xe0
      [  368.106005]  [<ffffffff810971c0>] ? kthread_create_on_node+0x140/0x140
      [  368.106005]  [<ffffffff816147d8>] ret_from_fork+0x58/0x90
      [  368.106005]  [<ffffffff810971c0>] ? kthread_create_on_node+0x140/0x140
      
      ==================================cut here==============================
      
      It turns out that the rcuos callback-offload kthread is busy processing
      a very large quantity of RCU callbacks, and it is not reliquishing the
      CPU while doing so.  This commit therefore adds an cond_resched_rcu_qs()
      within the loop to allow other tasks to run.
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      [ paulmck: Substituted cond_resched_rcu_qs for cond_resched. ]
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Dhaval Giani <dhaval.giani@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfb704f9
    • Takashi Iwai's avatar
      ALSA: pcm : Call kill_fasync() in stream lock · 58cebd1a
      Takashi Iwai authored
      commit 3aa02cb6 upstream.
      
      Currently kill_fasync() is called outside the stream lock in
      snd_pcm_period_elapsed().  This is potentially racy, since the stream
      may get released even during the irq handler is running.  Although
      snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
      guarantee that the irq handler finishes, thus the kill_fasync() call
      outside the stream spin lock may be invoked after the substream is
      detached, as recently reported by KASAN.
      
      As a quick workaround, move kill_fasync() call inside the stream
      lock.  The fasync is rarely used interface, so this shouldn't have a
      big impact from the performance POV.
      
      Ideally, we should implement some sync mechanism for the proper finish
      of stream and irq handler.  But this oneliner should suffice for most
      cases, so far.
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      58cebd1a
    • Andy Lutomirski's avatar
      x86/traps: Ignore high word of regs->cs in early_fixup_exception() · 5a5f7030
      Andy Lutomirski authored
      commit fc0e81b2 upstream.
      
      On the 80486 DX, it seems that some exceptions may leave garbage in
      the high bits of CS.  This causes sporadic failures in which
      early_fixup_exception() refuses to fix up an exception.
      
      As far as I can tell, this has been buggy for a long time, but the
      problem seems to have been exacerbated by commits:
      
        1e02ce4c ("x86: Store a per-cpu shadow copy of CR4")
        e1bfc11c ("x86/init: Fix cr4_init_shadow() on CR4-less machines")
      
      This appears to have broken for as long as we've had early
      exception handling.
      
      [ This backport should apply to kernels from 3.4 - 4.5. ]
      
      Fixes: 4c5023a3 ("x86-32: Handle exception table entries during early boot")
      Cc: H. Peter Anvin <hpa@zytor.com>
      Reported-by: default avatarMatthew Whitehead <tedheadster@gmail.com>
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a5f7030
    • Dmitry Vyukov's avatar
      kasan: update kasan_global for gcc 7 · 99576162
      Dmitry Vyukov authored
      commit 045d599a upstream.
      
      kasan_global struct is part of compiler/runtime ABI.  gcc revision
      241983 has added a new field to kasan_global struct.  Update kernel
      definition of kasan_global struct to include the new field.
      
      Without this patch KASAN is broken with gcc 7.
      
      Link: http://lkml.kernel.org/r/1479219743-28682-1-git-send-email-dvyukov@google.comSigned-off-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      99576162
    • Takashi Iwai's avatar
      zram: fix unbalanced idr management at hot removal · 61ab6247
      Takashi Iwai authored
      commit 529e71e1 upstream.
      
      The zram hot removal code calls idr_remove() even when zram_remove()
      returns an error (typically -EBUSY).  This results in a leftover at the
      device release, eventually leading to a crash when the module is
      reloaded.
      
      As described in the bug report below, the following procedure would
      cause an Oops with zram:
      
       - provision three zram devices via modprobe zram num_devices=3
       - configure a size for each device
         + echo "1G" > /sys/block/$zram_name/disksize
       - mkfs and mount zram0 only
       - attempt to hot remove all three devices
         + echo 2 > /sys/class/zram-control/hot_remove
         + echo 1 > /sys/class/zram-control/hot_remove
         + echo 0 > /sys/class/zram-control/hot_remove
           - zram0 removal fails with EBUSY, as expected
       - unmount zram0
       - try zram0 hot remove again
         + echo 0 > /sys/class/zram-control/hot_remove
           - fails with ENODEV (unexpected)
       - unload zram kernel module
         + completes successfully
       - zram0 device node still exists
       - attempt to mount /dev/zram0
         + mount command is killed
         + following BUG is encountered
      
       BUG: unable to handle kernel paging request at ffffffffa0002ba0
       IP: get_disk+0x16/0x50
       Oops: 0000 [#1] SMP
       CPU: 0 PID: 252 Comm: mount Not tainted 4.9.0-rc6 #176
       Call Trace:
         exact_lock+0xc/0x20
         kobj_lookup+0xdc/0x160
         get_gendisk+0x2f/0x110
         __blkdev_get+0x10c/0x3c0
         blkdev_get+0x19d/0x2e0
         blkdev_open+0x56/0x70
         do_dentry_open.isra.19+0x1ff/0x310
         vfs_open+0x43/0x60
         path_openat+0x2c9/0xf30
         do_filp_open+0x79/0xd0
         do_sys_open+0x114/0x1e0
         SyS_open+0x19/0x20
         entry_SYSCALL_64_fastpath+0x13/0x94
      
      This patch adds the proper error check in hot_remove_store() not to call
      idr_remove() unconditionally.
      
      Fixes: 17ec4cd9 ("zram: don't call idr_remove() from zram_remove()")
      Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1010970
      Link: http://lkml.kernel.org/r/20161121132140.12683-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Reviewed-by: default avatarDavid Disseldorp <ddiss@suse.de>
      Reported-by: default avatarDavid Disseldorp <ddiss@suse.de>
      Tested-by: default avatarDavid Disseldorp <ddiss@suse.de>
      Acked-by: default avatarMinchan Kim <minchan@kernel.org>
      Acked-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61ab6247
    • Vineet Gupta's avatar
      ARC: Don't use "+l" inline asm constraint · 5b2ed6e5
      Vineet Gupta authored
      commit 3c7c7a2f upstream.
      
      Apparenty this is coming in the way of gcc fix which inhibits the usage
      of LP_COUNT as a gpr.
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b2ed6e5
  3. 02 Dec, 2016 14 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.36 · 87c6c6ef
      Greg Kroah-Hartman authored
      87c6c6ef
    • Suganath Prabu S's avatar
      scsi: mpt3sas: Unblock device after controller reset · 6eddf5c9
      Suganath Prabu S authored
      commit 7ff723ad upstream.
      
      While issuing any ATA passthrough command to firmware the driver will
      block the device. But it will unblock the device only if the I/O
      completes through the ISR path. If a controller reset occurs before
      command completion the device will remain in blocked state.
      
      Make sure we unblock the device following a controller reset if an ATA
      passthrough command was queued.
      
      [mkp: clarified patch description]
      
      Fixes: ac6c2a93bd07 ("mpt3sas: Fix for SATA drive in blocked state, after diag reset")
      Signed-off-by: default avatarSuganath Prabu S <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6eddf5c9
    • Eric Dumazet's avatar
      flow_dissect: call init_default_flow_dissectors() earlier · c178e480
      Eric Dumazet authored
      commit c9b8af13 upstream.
      
      Andre Noll reported panics after my recent fix (commit 34fad54c
      "net: __skb_flow_dissect() must cap its return value")
      
      After some more headaches, Alexander root caused the problem to
      init_default_flow_dissectors() being called too late, in case
      a network driver like IGB is not a module and receives DHCP message
      very early.
      
      Fix is to call init_default_flow_dissectors() much earlier,
      as it is a core infrastructure and does not depend on another
      kernel service.
      
      Fixes: 06635a35 ("flow_dissect: use programable dissector in skb_flow_dissect and friends")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarAndre Noll <maan@tuebingen.mpg.de>
      Diagnosed-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c178e480
    • Tomas Winkler's avatar
      mei: fix return value on disconnection · 0b7860d6
      Tomas Winkler authored
      commit 2d4d5481 upstream.
      
      Correct errno on client disconnection is -ENODEV not -EBUSY
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b7860d6
    • Tomas Winkler's avatar
      mei: me: fix place for kaby point device ids. · bab2f72f
      Tomas Winkler authored
      This is fix of the backported patch only, it places
      KBL DIDs on correct place to easy on backporting of
      further DIDs.
      
      Fixes: 5c99f32c ('mei: me: add kaby point device ids')
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bab2f72f
    • Tomas Winkler's avatar
      mei: me: disable driver on SPT SPS firmware · 4f13967e
      Tomas Winkler authored
      commit 8c57cac1 upstream.
      
      Sunrise Point PCH with SPS Firmware doesn't expose working
      MEI interface, we need to quirk it out.
      The SPS Firmware is identifiable only on the first PCI function
      of the device.
      Tested-by: default avatarSujith Pandel <sujith_pandel@dell.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      4f13967e
    • Michel Dänzer's avatar
      drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on · e1049372
      Michel Dänzer authored
      NOTE: This patch only applies to 4.5.y or older kernels. With newer
      kernels, this problem cannot happen because the driver now uses
      drm_crtc_vblank_on/off instead of drm_vblank_pre/post_modeset[0]. I
      consider this patch safer for older kernels than backporting the API
      change, because drm_crtc_vblank_on/off had various issues in older
      kernels, and I'm not sure all fixes for those have been backported to
      all stable branches where this patch could be applied.
      
          ---------------------
      
      Fixes the vblank interrupt being disabled when it should be on, which
      can cause at least the following symptoms:
      
      * Hangs when running 'xset dpms force off' in a GNOME session with
        gnome-shell using DRI2.
      * RandR 1.4 slave outputs freezing with garbage displayed using
        xf86-video-ati 7.8.0 or newer.
      
      [0] See upstream commit:
      
      commit 777e3cbc
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Thu Jan 21 11:08:57 2016 +0100
      
          drm/radeon: Switch to drm_vblank_on/off
      Reported-and-Tested-by: default avatarMax Staudt <mstaudt@suse.de>
      Reviewed-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      e1049372
    • Andrey Ryabinin's avatar
      mpi: Fix NULL ptr dereference in mpi_powm() [ver #3] · 24909083
      Andrey Ryabinin authored
      commit f5527fff upstream.
      
      This fixes CVE-2016-8650.
      
      If mpi_powm() is given a zero exponent, it wants to immediately return
      either 1 or 0, depending on the modulus.  However, if the result was
      initalised with zero limb space, no limbs space is allocated and a
      NULL-pointer exception ensues.
      
      Fix this by allocating a minimal amount of limb space for the result when
      the 0-exponent case when the result is 1 and not touching the limb space
      when the result is 0.
      
      This affects the use of RSA keys and X.509 certificates that carry them.
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
      PGD 0
      Oops: 0002 [#1] SMP
      Modules linked in:
      CPU: 3 PID: 3014 Comm: keyctl Not tainted 4.9.0-rc6-fscache+ #278
      Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
      task: ffff8804011944c0 task.stack: ffff880401294000
      RIP: 0010:[<ffffffff8138ce5d>]  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
      RSP: 0018:ffff880401297ad8  EFLAGS: 00010212
      RAX: 0000000000000000 RBX: ffff88040868bec0 RCX: ffff88040868bba0
      RDX: ffff88040868b260 RSI: ffff88040868bec0 RDI: ffff88040868bee0
      RBP: ffff880401297ba8 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000047 R11: ffffffff8183b210 R12: 0000000000000000
      R13: ffff8804087c7600 R14: 000000000000001f R15: ffff880401297c50
      FS:  00007f7a7918c700(0000) GS:ffff88041fb80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 0000000401250000 CR4: 00000000001406e0
      Stack:
       ffff88040868bec0 0000000000000020 ffff880401297b00 ffffffff81376cd4
       0000000000000100 ffff880401297b10 ffffffff81376d12 ffff880401297b30
       ffffffff81376f37 0000000000000100 0000000000000000 ffff880401297ba8
      Call Trace:
       [<ffffffff81376cd4>] ? __sg_page_iter_next+0x43/0x66
       [<ffffffff81376d12>] ? sg_miter_get_next_page+0x1b/0x5d
       [<ffffffff81376f37>] ? sg_miter_next+0x17/0xbd
       [<ffffffff8138ba3a>] ? mpi_read_raw_from_sgl+0xf2/0x146
       [<ffffffff8132a95c>] rsa_verify+0x9d/0xee
       [<ffffffff8132acca>] ? pkcs1pad_sg_set_buf+0x2e/0xbb
       [<ffffffff8132af40>] pkcs1pad_verify+0xc0/0xe1
       [<ffffffff8133cb5e>] public_key_verify_signature+0x1b0/0x228
       [<ffffffff8133d974>] x509_check_for_self_signed+0xa1/0xc4
       [<ffffffff8133cdde>] x509_cert_parse+0x167/0x1a1
       [<ffffffff8133d609>] x509_key_preparse+0x21/0x1a1
       [<ffffffff8133c3d7>] asymmetric_key_preparse+0x34/0x61
       [<ffffffff812fc9f3>] key_create_or_update+0x145/0x399
       [<ffffffff812fe227>] SyS_add_key+0x154/0x19e
       [<ffffffff81001c2b>] do_syscall_64+0x80/0x191
       [<ffffffff816825e4>] entry_SYSCALL64_slow_path+0x25/0x25
      Code: 56 41 55 41 54 53 48 81 ec a8 00 00 00 44 8b 71 04 8b 42 04 4c 8b 67 18 45 85 f6 89 45 80 0f 84 b4 06 00 00 85 c0 75 2f 41 ff ce <49> c7 04 24 01 00 00 00 b0 01 75 0b 48 8b 41 18 48 83 38 01 0f
      RIP  [<ffffffff8138ce5d>] mpi_powm+0x32/0x7e6
       RSP <ffff880401297ad8>
      CR2: 0000000000000000
      ---[ end trace d82015255d4a5d8d ]---
      
      Basically, this is a backport of a libgcrypt patch:
      
      	http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526
      
      Fixes: cdec9cb5 ("crypto: GnuPG based MPI lib - source files (part 1)")
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
      cc: linux-ima-devel@lists.sourceforge.net
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24909083
    • John David Anglin's avatar
      parisc: Also flush data TLB in flush_icache_page_asm · cd4235a7
      John David Anglin authored
      commit 5035b230 upstream.
      
      This is the second issue I noticed in reviewing the parisc TLB code.
      
      The fic instruction may use either the instruction or data TLB in
      flushing the instruction cache.  Thus, on machines with a split TLB, we
      should also flush the data TLB after setting up the temporary alias
      registers.
      
      Although this has no functional impact, I changed the pdtlb and pitlb
      instructions to consistently use the index register %r0.  These
      instructions do not support integer displacements.
      
      Tested on rp3440 and c8000.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd4235a7
    • John David Anglin's avatar
      parisc: Fix race in pci-dma.c · 7a1ab6a2
      John David Anglin authored
      commit c0452fb9 upstream.
      
      We are still troubled by occasional random segmentation faults and
      memory memory corruption on SMP machines.  The causes quite a few
      package builds to fail on the Debian buildd machines for parisc.  When
      gcc-6 failed to build three times in a row, I looked again at the TLB
      related code.  I found a couple of issues.  This is the first.
      
      In general, we need to ensure page table updates and corresponding TLB
      purges are atomic.  The attached patch fixes an instance in pci-dma.c
      where the page table update was not guarded by the TLB lock.
      
      Tested on rp3440 and c8000.  So far, no further random segmentation
      faults have been observed.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a1ab6a2
    • John David Anglin's avatar
      parisc: Fix races in parisc_setup_cache_timing() · e541fd81
      John David Anglin authored
      commit 741dc7bf upstream.
      
      Helge reported to me the following startup crash:
      
      [    0.000000] Linux version 4.8.0-1-parisc64-smp (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161019 (GCC) ) #1 SMP Debian 4.8.7-1 (2016-11-13)
      [    0.000000] The 64-bit Kernel has started...
      [    0.000000] Kernel default page size is 4 KB. Huge pages enabled with 1 MB physical and 2 MB virtual size.
      [    0.000000] Determining PDC firmware type: System Map.
      [    0.000000] model 9000/785/J5000
      [    0.000000] Total Memory: 2048 MB
      [    0.000000] Memory: 2018528K/2097152K available (9272K kernel code, 3053K rwdata, 1319K rodata, 1024K init, 840K bss, 78624K reserved, 0K cma-reserved)
      [    0.000000] virtual kernel memory layout:
      [    0.000000]     vmalloc : 0x0000000000008000 - 0x000000003f000000   (1007 MB)
      [    0.000000]     memory  : 0x0000000040000000 - 0x00000000c0000000   (2048 MB)
      [    0.000000]       .init : 0x0000000040100000 - 0x0000000040200000   (1024 kB)
      [    0.000000]       .data : 0x0000000040b0e000 - 0x0000000040f533e0   (4372 kB)
      [    0.000000]       .text : 0x0000000040200000 - 0x0000000040b0e000   (9272 kB)
      [    0.768910] Brought up 1 CPUs
      [    0.992465] NET: Registered protocol family 16
      [    2.429981] Releasing cpu 1 now, hpa=fffffffffffa2000
      [    2.635751] CPU(s): 2 out of 2 PA8500 (PCX-W) at 440.000000 MHz online
      [    2.726692] Setting cache flush threshold to 1024 kB
      [    2.729932] Not-handled unaligned insn 0x43ffff80
      [    2.798114] Setting TLB flush threshold to 140 kB
      [    2.928039] Unaligned handler failed, ret = -1
      [    3.000419]       _______________________________
      [    3.000419]      < Your System ate a SPARC! Gah! >
      [    3.000419]       -------------------------------
      [    3.000419]              \   ^__^
      [    3.000419]                  (__)\       )\/\
      [    3.000419]                   U  ||----w |
      [    3.000419]                      ||     ||
      [    9.340055] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-1-parisc64-smp #1 Debian 4.8.7-1
      [    9.448082] task: 00000000bfd48060 task.stack: 00000000bfd50000
      [    9.528040]
      [   10.760029] IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004025d154 000000004025d158
      [   10.868052]  IIR: 43ffff80    ISR: 0000000000340000  IOR: 000001ff54150960
      [   10.960029]  CPU:        1   CR30: 00000000bfd50000 CR31: 0000000011111111
      [   11.052057]  ORIG_R28: 000000004021e3b4
      [   11.100045]  IAOQ[0]: irq_exit+0x94/0x120
      [   11.152062]  IAOQ[1]: irq_exit+0x98/0x120
      [   11.208031]  RP(r2): irq_exit+0xb8/0x120
      [   11.256074] Backtrace:
      [   11.288067]  [<00000000402cd944>] cpu_startup_entry+0x1e4/0x598
      [   11.368058]  [<0000000040109528>] smp_callin+0x2c0/0x2f0
      [   11.436308]  [<00000000402b53fc>] update_curr+0x18c/0x2d0
      [   11.508055]  [<00000000402b73b8>] dequeue_entity+0x2c0/0x1030
      [   11.584040]  [<00000000402b3cc0>] set_next_entity+0x80/0xd30
      [   11.660069]  [<00000000402c1594>] pick_next_task_fair+0x614/0x720
      [   11.740085]  [<000000004020dd34>] __schedule+0x394/0xa60
      [   11.808054]  [<000000004020e488>] schedule+0x88/0x118
      [   11.876039]  [<0000000040283d3c>] rescuer_thread+0x4d4/0x5b0
      [   11.948090]  [<000000004028fc4c>] kthread+0x1ec/0x248
      [   12.016053]  [<0000000040205020>] end_fault_vector+0x20/0xc0
      [   12.092239]  [<00000000402050c0>] _switch_to_ret+0x0/0xf40
      [   12.164044]
      [   12.184036] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-1-parisc64-smp #1 Debian 4.8.7-1
      [   12.244040] Backtrace:
      [   12.244040]  [<000000004021c480>] show_stack+0x68/0x80
      [   12.244040]  [<00000000406f332c>] dump_stack+0xec/0x168
      [   12.244040]  [<000000004021c74c>] die_if_kernel+0x25c/0x430
      [   12.244040]  [<000000004022d320>] handle_unaligned+0xb48/0xb50
      [   12.244040]
      [   12.632066] ---[ end trace 9ca05a7215c7bbb2 ]---
      [   12.692036] Kernel panic - not syncing: Attempted to kill the idle task!
      
      We have the insn 0x43ffff80 in IIR but from IAOQ we should have:
         4025d150:   0f f3 20 df     ldd,s r19(r31),r31
         4025d154:   0f 9f 00 9c     ldw r31(ret0),ret0
         4025d158:   bf 80 20 58     cmpb,*<> r0,ret0,4025d18c <irq_exit+0xcc>
      
      Cpu0 has just completed running parisc_setup_cache_timing:
      
      [    2.429981] Releasing cpu 1 now, hpa=fffffffffffa2000
      [    2.635751] CPU(s): 2 out of 2 PA8500 (PCX-W) at 440.000000 MHz online
      [    2.726692] Setting cache flush threshold to 1024 kB
      [    2.729932] Not-handled unaligned insn 0x43ffff80
      [    2.798114] Setting TLB flush threshold to 140 kB
      [    2.928039] Unaligned handler failed, ret = -1
      
      From the backtrace, cpu1 is in smp_callin:
      
      void __init smp_callin(void)
      {
             int slave_id = cpu_now_booting;
      
             smp_cpu_init(slave_id);
             preempt_disable();
      
             flush_cache_all_local(); /* start with known state */
             flush_tlb_all_local(NULL);
      
             local_irq_enable();  /* Interrupts have been off until now */
      
             cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
      
      So, it has just flushed its caches and the TLB. It would seem either the
      flushes in parisc_setup_cache_timing or smp_callin have corrupted kernel
      memory.
      
      The attached patch reworks parisc_setup_cache_timing to remove the races
      in setting the cache and TLB flush thresholds. It also corrects the
      number of bytes flushed in the TLB calculation.
      
      The patch flushes the cache and TLB on cpu0 before starting the
      secondary processors so that they are started from a known state.
      
      Tested with a few reboots on c8000.
      Signed-off-by: default avatarJohn David Anglin  <dave.anglin@bell.net>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e541fd81
    • Arnd Bergmann's avatar
      NFSv4.x: hide array-bounds warning · 0c0ddbf7
      Arnd Bergmann authored
      commit d55b352b upstream.
      
      A correct bugfix introduced a harmless warning that shows up with gcc-7:
      
      fs/nfs/callback.c: In function 'nfs_callback_up':
      fs/nfs/callback.c:214:14: error: array subscript is outside array bounds [-Werror=array-bounds]
      
      What happens here is that the 'minorversion == 0' check tells the
      compiler that we assume minorversion can be something other than 0,
      but when CONFIG_NFS_V4_1 is disabled that would be invalid and
      result in an out-of-bounds access.
      
      The added check for IS_ENABLED(CONFIG_NFS_V4_1) tells gcc that this
      really can't happen, which makes the code slightly smaller and also
      avoids the warning.
      
      The bugfix that introduced the warning is marked for stable backports,
      we want this one backported to the same releases.
      
      Fixes: 98b0f80c ("NFSv4.x: Fix a refcount leak in nfs_callback_up_net")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c0ddbf7
    • John Johansen's avatar
      apparmor: fix change_hat not finding hat after policy replacement · be79d7fa
      John Johansen authored
      commit 3d40658c upstream.
      
      After a policy replacement, the task cred may be out of date and need
      to be updated. However change_hat is using the stale profiles from
      the out of date cred resulting in either: a stale profile being applied
      or, incorrect failure when searching for a hat profile as it has been
      migrated to the new parent profile.
      
      Fixes: 01e2b670 (failure to find hat)
      Fixes: 898127c3 (stale policy being applied)
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000287Signed-off-by: default avatarJohn Johansen <john.johansen@canonical.com>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be79d7fa
    • Johannes Berg's avatar
      cfg80211: limit scan results cache size · 8316338a
      Johannes Berg authored
      commit 9853a55e upstream.
      
      It's possible to make scanning consume almost arbitrary amounts
      of memory, e.g. by sending beacon frames with random BSSIDs at
      high rates while somebody is scanning.
      
      Limit the number of BSS table entries we're willing to cache to
      1000, limiting maximum memory usage to maybe 4-5MB, but lower
      in practice - that would be the case for having both full-sized
      beacon and probe response frames for each entry; this seems not
      possible in practice, so a limit of 1000 entries will likely be
      closer to 0.5 MB.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8316338a