1. 22 Mar, 2017 29 commits
    • Eric Dumazet's avatar
      tcp: fix various issues for sockets morphing to listen state · 81a43770
      Eric Dumazet authored
      [ Upstream commit 02b2faaf ]
      
      Dmitry Vyukov reported a divide by 0 triggered by syzkaller, exploiting
      tcp_disconnect() path that was never really considered and/or used
      before syzkaller ;)
      
      I was not able to reproduce the bug, but it seems issues here are the
      three possible actions that assumed they would never trigger on a
      listener.
      
      1) tcp_write_timer_handler
      2) tcp_delack_timer_handler
      3) MTU reduction
      
      Only IPv6 MTU reduction was properly testing TCP_CLOSE and TCP_LISTEN
       states from tcp_v6_mtu_reduced()
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81a43770
    • WANG Cong's avatar
      strparser: destroy workqueue on module exit · 178e86ff
      WANG Cong authored
      [ Upstream commit f78ef7cd ]
      
      Fixes: 43a0c675 ("strparser: Stream parser for messages")
      Cc: Tom Herbert <tom@herbertland.com>
      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>
      178e86ff
    • WANG Cong's avatar
      bonding: use ETH_MAX_MTU as max mtu · aa677aaf
      WANG Cong authored
      [ Upstream commit 31c05415 ]
      
      This restores the ability of setting bond device's mtu to 9000.
      
      Fixes: 91572088 ("net: use core MTU range checking in core net infra")
      Reported-by: daznis@gmail.com
      Reported-by: default avatarBrad Campbell <lists2009@fnarfbargle.com>
      Cc: Jarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa677aaf
    • Lendacky, Thomas's avatar
      amd-xgbe: Don't overwrite SFP PHY mod_absent settings · 0ee7666f
      Lendacky, Thomas authored
      [ Upstream commit 2697ea5a ]
      
      If an SFP module is not present, xgbe_phy_sfp_phy_settings() should
      return after applying the default settings. Currently there is no return
      statement and the default settings are overwritten.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ee7666f
    • Lendacky, Thomas's avatar
      amd-xgbe: Be sure to set MDIO modes on device (re)start · 9919f222
      Lendacky, Thomas authored
      [ Upstream commit b42c6761 ]
      
      The MDIO register mode is set when the device is probed. But when the
      device is brought down and then back up, the MDIO register mode has been
      reset.  Be sure to reset the mode during device startup and only change
      the mode of the address specified.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9919f222
    • Lendacky, Thomas's avatar
      amd-xgbe: Stop the PHY before releasing interrupts · 4381ffdf
      Lendacky, Thomas authored
      [ Upstream commit 402168b4 ]
      
      Some configurations require the use of the hardware's MDIO support to
      communicate with external PHYs. The MDIO commands indicate completion
      through the device interrupt. When bringing down the device the interrupts
      were released before stopping the external PHY, resulting in MDIO command
      timeouts. Move the stopping of the PHY to before the releasing of the
      interrupts.
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4381ffdf
    • Arnaldo Carvalho de Melo's avatar
      dccp: Unlock sock before calling sk_free() · 7558c56c
      Arnaldo Carvalho de Melo authored
      [ Upstream commit d5afb6f9 ]
      
      The code where sk_clone() came from created a new socket and locked it,
      but then, on the error path didn't unlock it.
      
      This problem stayed there for a long while, till b0691c8e ("net:
      Unlock sock before calling sk_free()") fixed it, but unfortunately the
      callers of sk_clone() (now sk_clone_locked()) were not audited and the
      one in dccp_create_openreq_child() remained.
      
      Now in the age of the syskaller fuzzer, this was finally uncovered, as
      reported by Dmitry:
      
       ---- 8< ----
      
      I've got the following report while running syzkaller fuzzer on
      86292b33 ("Merge branch 'akpm' (patches from Andrew)")
      
        [ BUG: held lock freed! ]
        4.10.0+ #234 Not tainted
        -------------------------
        syz-executor6/6898 is freeing memory
        ffff88006286cac0-ffff88006286d3b7, with a lock still held there!
         (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] spin_lock
        include/linux/spinlock.h:299 [inline]
         (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>]
        sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504
        5 locks held by syz-executor6/6898:
         #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff839a34b4>] lock_sock
        include/net/sock.h:1460 [inline]
         #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff839a34b4>]
        inet_stream_connect+0x44/0xa0 net/ipv4/af_inet.c:681
         #1:  (rcu_read_lock){......}, at: [<ffffffff83bc1c2a>]
        inet6_csk_xmit+0x12a/0x5d0 net/ipv6/inet6_connection_sock.c:126
         #2:  (rcu_read_lock){......}, at: [<ffffffff8369b424>] __skb_unlink
        include/linux/skbuff.h:1767 [inline]
         #2:  (rcu_read_lock){......}, at: [<ffffffff8369b424>] __skb_dequeue
        include/linux/skbuff.h:1783 [inline]
         #2:  (rcu_read_lock){......}, at: [<ffffffff8369b424>]
        process_backlog+0x264/0x730 net/core/dev.c:4835
         #3:  (rcu_read_lock){......}, at: [<ffffffff83aeb5c0>]
        ip6_input_finish+0x0/0x1700 net/ipv6/ip6_input.c:59
         #4:  (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] spin_lock
        include/linux/spinlock.h:299 [inline]
         #4:  (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>]
        sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504
      
      Fix it just like was done by b0691c8e ("net: Unlock sock before calling
      sk_free()").
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Cong Wang <xiyou.wangcong@gmail.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170301153510.GE15145@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7558c56c
    • Eric Dumazet's avatar
      ipv6: orphan skbs in reassembly unit · a8ee7ed1
      Eric Dumazet authored
      [ Upstream commit 48cac18e ]
      
      Andrey reported a use-after-free in IPv6 stack.
      
      Issue here is that we free the socket while it still has skb
      in TX path and in some queues.
      
      It happens here because IPv6 reassembly unit messes skb->truesize,
      breaking skb_set_owner_w() badly.
      
      We fixed a similar issue for IPV4 in commit 8282f274 ("inet: frag:
      Always orphan skbs inside ip_defrag()")
      Acked-by: default avatarJoe Stringer <joe@ovn.org>
      
      ==================================================================
      BUG: KASAN: use-after-free in sock_wfree+0x118/0x120
      Read of size 8 at addr ffff880062da0060 by task a.out/4140
      
      page:ffffea00018b6800 count:1 mapcount:0 mapping:          (null)
      index:0x0 compound_mapcount: 0
      flags: 0x100000000008100(slab|head)
      raw: 0100000000008100 0000000000000000 0000000000000000 0000000180130013
      raw: dead000000000100 dead000000000200 ffff88006741f140 0000000000000000
      page dumped because: kasan: bad access detected
      
      CPU: 0 PID: 4140 Comm: a.out Not tainted 4.10.0-rc3+ #59
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:15
       dump_stack+0x292/0x398 lib/dump_stack.c:51
       describe_address mm/kasan/report.c:262
       kasan_report_error+0x121/0x560 mm/kasan/report.c:370
       kasan_report mm/kasan/report.c:392
       __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:413
       sock_flag ./arch/x86/include/asm/bitops.h:324
       sock_wfree+0x118/0x120 net/core/sock.c:1631
       skb_release_head_state+0xfc/0x250 net/core/skbuff.c:655
       skb_release_all+0x15/0x60 net/core/skbuff.c:668
       __kfree_skb+0x15/0x20 net/core/skbuff.c:684
       kfree_skb+0x16e/0x4e0 net/core/skbuff.c:705
       inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
       inet_frag_put ./include/net/inet_frag.h:133
       nf_ct_frag6_gather+0x1125/0x38b0 net/ipv6/netfilter/nf_conntrack_reasm.c:617
       ipv6_defrag+0x21b/0x350 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
       nf_hook_entry_hookfn ./include/linux/netfilter.h:102
       nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
       nf_hook ./include/linux/netfilter.h:212
       __ip6_local_out+0x52c/0xaf0 net/ipv6/output_core.c:160
       ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
       ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
       ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
       rawv6_push_pending_frames net/ipv6/raw.c:613
       rawv6_sendmsg+0x2cff/0x4130 net/ipv6/raw.c:927
       inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
       sock_sendmsg_nosec net/socket.c:635
       sock_sendmsg+0xca/0x110 net/socket.c:645
       sock_write_iter+0x326/0x620 net/socket.c:848
       new_sync_write fs/read_write.c:499
       __vfs_write+0x483/0x760 fs/read_write.c:512
       vfs_write+0x187/0x530 fs/read_write.c:560
       SYSC_write fs/read_write.c:607
       SyS_write+0xfb/0x230 fs/read_write.c:599
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      RIP: 0033:0x7ff26e6f5b79
      RSP: 002b:00007ff268e0ed98 EFLAGS: 00000206 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 00007ff268e0f9c0 RCX: 00007ff26e6f5b79
      RDX: 0000000000000010 RSI: 0000000020f50fe1 RDI: 0000000000000003
      RBP: 00007ff26ebc1220 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
      R13: 00007ff268e0f9c0 R14: 00007ff26efec040 R15: 0000000000000003
      
      The buggy address belongs to the object at ffff880062da0000
       which belongs to the cache RAWv6 of size 1504
      The buggy address ffff880062da0060 is located 96 bytes inside
       of 1504-byte region [ffff880062da0000, ffff880062da05e0)
      
      Freed by task 4113:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
       save_stack+0x43/0xd0 mm/kasan/kasan.c:502
       set_track mm/kasan/kasan.c:514
       kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
       slab_free_hook mm/slub.c:1352
       slab_free_freelist_hook mm/slub.c:1374
       slab_free mm/slub.c:2951
       kmem_cache_free+0xb2/0x2c0 mm/slub.c:2973
       sk_prot_free net/core/sock.c:1377
       __sk_destruct+0x49c/0x6e0 net/core/sock.c:1452
       sk_destruct+0x47/0x80 net/core/sock.c:1460
       __sk_free+0x57/0x230 net/core/sock.c:1468
       sk_free+0x23/0x30 net/core/sock.c:1479
       sock_put ./include/net/sock.h:1638
       sk_common_release+0x31e/0x4e0 net/core/sock.c:2782
       rawv6_close+0x54/0x80 net/ipv6/raw.c:1214
       inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
       inet6_release+0x50/0x70 net/ipv6/af_inet6.c:431
       sock_release+0x8d/0x1e0 net/socket.c:599
       sock_close+0x16/0x20 net/socket.c:1063
       __fput+0x332/0x7f0 fs/file_table.c:208
       ____fput+0x15/0x20 fs/file_table.c:244
       task_work_run+0x19b/0x270 kernel/task_work.c:116
       exit_task_work ./include/linux/task_work.h:21
       do_exit+0x186b/0x2800 kernel/exit.c:839
       do_group_exit+0x149/0x420 kernel/exit.c:943
       SYSC_exit_group kernel/exit.c:954
       SyS_exit_group+0x1d/0x20 kernel/exit.c:952
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      
      Allocated by task 4115:
       save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
       save_stack+0x43/0xd0 mm/kasan/kasan.c:502
       set_track mm/kasan/kasan.c:514
       kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:605
       kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:544
       slab_post_alloc_hook mm/slab.h:432
       slab_alloc_node mm/slub.c:2708
       slab_alloc mm/slub.c:2716
       kmem_cache_alloc+0x1af/0x250 mm/slub.c:2721
       sk_prot_alloc+0x65/0x2a0 net/core/sock.c:1334
       sk_alloc+0x105/0x1010 net/core/sock.c:1396
       inet6_create+0x44d/0x1150 net/ipv6/af_inet6.c:183
       __sock_create+0x4f6/0x880 net/socket.c:1199
       sock_create net/socket.c:1239
       SYSC_socket net/socket.c:1269
       SyS_socket+0xf9/0x230 net/socket.c:1249
       entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
      
      Memory state around the buggy address:
       ffff880062d9ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff880062d9ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff880062da0000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880062da0080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880062da0100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8ee7ed1
    • Eric Dumazet's avatar
      net: net_enable_timestamp() can be called from irq contexts · eb39579a
      Eric Dumazet authored
      [ Upstream commit 13baa00a ]
      
      It is now very clear that silly TCP listeners might play with
      enabling/disabling timestamping while new children are added
      to their accept queue.
      
      Meaning net_enable_timestamp() can be called from BH context
      while current state of the static key is not enabled.
      
      Lets play safe and allow all contexts.
      
      The work queue is scheduled only under the problematic cases,
      which are the static key enable/disable transition, to not slow down
      critical paths.
      
      This extends and improves what we did in commit 5fa8bbda ("net: use
      a work queue to defer net_disable_timestamp() work")
      
      Fixes: b90e5794 ("net: dont call jump_label_dec from irq context")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb39579a
    • Alexander Potapenko's avatar
      net: don't call strlen() on the user buffer in packet_bind_spkt() · fa8bc7b4
      Alexander Potapenko authored
      [ Upstream commit 540e2894 ]
      
      KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
      uninitialized memory in packet_bind_spkt():
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      
      ==================================================================
      BUG: KMSAN: use of unitialized memory
      CPU: 0 PID: 1074 Comm: packet Not tainted 4.8.0-rc6+ #1891
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
      01/01/2011
       0000000000000000 ffff88006b6dfc08 ffffffff82559ae8 ffff88006b6dfb48
       ffffffff818a7c91 ffffffff85b9c870 0000000000000092 ffffffff85b9c550
       0000000000000000 0000000000000092 00000000ec400911 0000000000000002
      Call Trace:
       [<     inline     >] __dump_stack lib/dump_stack.c:15
       [<ffffffff82559ae8>] dump_stack+0x238/0x290 lib/dump_stack.c:51
       [<ffffffff818a6626>] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1003
       [<ffffffff818a783b>] __msan_warning+0x5b/0xb0
      mm/kmsan/kmsan_instr.c:424
       [<     inline     >] strlen lib/string.c:484
       [<ffffffff8259b58d>] strlcpy+0x9d/0x200 lib/string.c:144
       [<ffffffff84b2eca4>] packet_bind_spkt+0x144/0x230
      net/packet/af_packet.c:3132
       [<ffffffff84242e4d>] SYSC_bind+0x40d/0x5f0 net/socket.c:1370
       [<ffffffff84242a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
       [<ffffffff8515991b>] entry_SYSCALL_64_fastpath+0x13/0x8f
      arch/x86/entry/entry_64.o:?
      chained origin: 00000000eba00911
       [<ffffffff810bb787>] save_stack_trace+0x27/0x50
      arch/x86/kernel/stacktrace.c:67
       [<     inline     >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
       [<     inline     >] kmsan_save_stack mm/kmsan/kmsan.c:334
       [<ffffffff818a59f8>] kmsan_internal_chain_origin+0x118/0x1e0
      mm/kmsan/kmsan.c:527
       [<ffffffff818a7773>] __msan_set_alloca_origin4+0xc3/0x130
      mm/kmsan/kmsan_instr.c:380
       [<ffffffff84242b69>] SYSC_bind+0x129/0x5f0 net/socket.c:1356
       [<ffffffff84242a22>] SyS_bind+0x82/0xa0 net/socket.c:1356
       [<ffffffff8515991b>] entry_SYSCALL_64_fastpath+0x13/0x8f
      arch/x86/entry/entry_64.o:?
      origin description: ----address@SYSC_bind (origin=00000000eb400911)
      ==================================================================
      (the line numbers are relative to 4.8-rc6, but the bug persists
      upstream)
      
      , when I run the following program as root:
      
      =====================================
       #include <string.h>
       #include <sys/socket.h>
       #include <netpacket/packet.h>
       #include <net/ethernet.h>
      
       int main() {
         struct sockaddr addr;
         memset(&addr, 0xff, sizeof(addr));
         addr.sa_family = AF_PACKET;
         int fd = socket(PF_PACKET, SOCK_PACKET, htons(ETH_P_ALL));
         bind(fd, &addr, sizeof(addr));
         return 0;
       }
      =====================================
      
      This happens because addr.sa_data copied from the userspace is not
      zero-terminated, and copying it with strlcpy() in packet_bind_spkt()
      results in calling strlen() on the kernel copy of that non-terminated
      buffer.
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fa8bc7b4
    • Mike Manning's avatar
      net: bridge: allow IPv6 when multicast flood is disabled · e89adaa7
      Mike Manning authored
      [ Upstream commit 8953de2f ]
      
      Even with multicast flooding turned off, IPv6 ND should still work so
      that IPv6 connectivity is provided. Allow this by continuing to flood
      multicast traffic originated by us.
      
      Fixes: b6cb5ac8 ("net: bridge: add per-port multicast flood flag")
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarMike Manning <mmanning@brocade.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e89adaa7
    • Eric Dumazet's avatar
      tcp/dccp: block BH for SYN processing · da2da823
      Eric Dumazet authored
      [ Upstream commit 449809a6 ]
      
      SYN processing really was meant to be handled from BH.
      
      When I got rid of BH blocking while processing socket backlog
      in commit 5413d1ba ("net: do not block BH while processing socket
      backlog"), I forgot that a malicious user could transition to TCP_LISTEN
      from a state that allowed (SYN) packets to be parked in the socket
      backlog while socket is owned by the thread doing the listen() call.
      
      Sure enough syzkaller found this and reported the bug ;)
      
      =================================
      [ INFO: inconsistent lock state ]
      4.10.0+ #60 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      syz-executor0/5090 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&hashinfo->ehash_locks[i])->rlock){+.?...}, at:
      [<ffffffff83a6a370>] spin_lock include/linux/spinlock.h:299 [inline]
       (&(&hashinfo->ehash_locks[i])->rlock){+.?...}, at:
      [<ffffffff83a6a370>] inet_ehash_insert+0x240/0xad0
      net/ipv4/inet_hashtables.c:407
      {IN-SOFTIRQ-W} state was registered at:
        mark_irqflags kernel/locking/lockdep.c:2923 [inline]
        __lock_acquire+0xbcf/0x3270 kernel/locking/lockdep.c:3295
        lock_acquire+0x241/0x580 kernel/locking/lockdep.c:3753
        __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
        _raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
        spin_lock include/linux/spinlock.h:299 [inline]
        inet_ehash_insert+0x240/0xad0 net/ipv4/inet_hashtables.c:407
        reqsk_queue_hash_req net/ipv4/inet_connection_sock.c:753 [inline]
        inet_csk_reqsk_queue_hash_add+0x1b7/0x2a0 net/ipv4/inet_connection_sock.c:764
        tcp_conn_request+0x25cc/0x3310 net/ipv4/tcp_input.c:6399
        tcp_v4_conn_request+0x157/0x220 net/ipv4/tcp_ipv4.c:1262
        tcp_rcv_state_process+0x802/0x4130 net/ipv4/tcp_input.c:5889
        tcp_v4_do_rcv+0x56b/0x940 net/ipv4/tcp_ipv4.c:1433
        tcp_v4_rcv+0x2e12/0x3210 net/ipv4/tcp_ipv4.c:1711
        ip_local_deliver_finish+0x4ce/0xc40 net/ipv4/ip_input.c:216
        NF_HOOK include/linux/netfilter.h:257 [inline]
        ip_local_deliver+0x1ce/0x710 net/ipv4/ip_input.c:257
        dst_input include/net/dst.h:492 [inline]
        ip_rcv_finish+0xb1d/0x2110 net/ipv4/ip_input.c:396
        NF_HOOK include/linux/netfilter.h:257 [inline]
        ip_rcv+0xd90/0x19c0 net/ipv4/ip_input.c:487
        __netif_receive_skb_core+0x1ad1/0x3400 net/core/dev.c:4179
        __netif_receive_skb+0x2a/0x170 net/core/dev.c:4217
        netif_receive_skb_internal+0x1d6/0x430 net/core/dev.c:4245
        napi_skb_finish net/core/dev.c:4602 [inline]
        napi_gro_receive+0x4e6/0x680 net/core/dev.c:4636
        e1000_receive_skb drivers/net/ethernet/intel/e1000/e1000_main.c:4033 [inline]
        e1000_clean_rx_irq+0x5e0/0x1490
      drivers/net/ethernet/intel/e1000/e1000_main.c:4489
        e1000_clean+0xb9a/0x2910 drivers/net/ethernet/intel/e1000/e1000_main.c:3834
        napi_poll net/core/dev.c:5171 [inline]
        net_rx_action+0xe70/0x1900 net/core/dev.c:5236
        __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
        invoke_softirq kernel/softirq.c:364 [inline]
        irq_exit+0x19e/0x1d0 kernel/softirq.c:405
        exiting_irq arch/x86/include/asm/apic.h:658 [inline]
        do_IRQ+0x81/0x1a0 arch/x86/kernel/irq.c:250
        ret_from_intr+0x0/0x20
        native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
        arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
        default_idle+0x8f/0x410 arch/x86/kernel/process.c:271
        arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:262
        default_idle_call+0x36/0x60 kernel/sched/idle.c:96
        cpuidle_idle_call kernel/sched/idle.c:154 [inline]
        do_idle+0x348/0x440 kernel/sched/idle.c:243
        cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:345
        start_secondary+0x344/0x440 arch/x86/kernel/smpboot.c:272
        verify_cpu+0x0/0xfc
      irq event stamp: 1741
      hardirqs last  enabled at (1741): [<ffffffff84d49d77>]
      __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160
      [inline]
      hardirqs last  enabled at (1741): [<ffffffff84d49d77>]
      _raw_spin_unlock_irqrestore+0xf7/0x1a0 kernel/locking/spinlock.c:191
      hardirqs last disabled at (1740): [<ffffffff84d4a732>]
      __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
      hardirqs last disabled at (1740): [<ffffffff84d4a732>]
      _raw_spin_lock_irqsave+0xa2/0x110 kernel/locking/spinlock.c:159
      softirqs last  enabled at (1738): [<ffffffff84d4deff>]
      __do_softirq+0x7cf/0xb7d kernel/softirq.c:310
      softirqs last disabled at (1571): [<ffffffff84d4b92c>]
      do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&hashinfo->ehash_locks[i])->rlock);
        <Interrupt>
          lock(&(&hashinfo->ehash_locks[i])->rlock);
      
       *** DEADLOCK ***
      
      1 lock held by syz-executor0/5090:
       #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83406b43>] lock_sock
      include/net/sock.h:1460 [inline]
       #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83406b43>]
      sock_setsockopt+0x233/0x1e40 net/core/sock.c:683
      
      stack backtrace:
      CPU: 1 PID: 5090 Comm: syz-executor0 Not tainted 4.10.0+ #60
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:15 [inline]
       dump_stack+0x292/0x398 lib/dump_stack.c:51
       print_usage_bug+0x3ef/0x450 kernel/locking/lockdep.c:2387
       valid_state kernel/locking/lockdep.c:2400 [inline]
       mark_lock_irq kernel/locking/lockdep.c:2602 [inline]
       mark_lock+0xf30/0x1410 kernel/locking/lockdep.c:3065
       mark_irqflags kernel/locking/lockdep.c:2941 [inline]
       __lock_acquire+0x6dc/0x3270 kernel/locking/lockdep.c:3295
       lock_acquire+0x241/0x580 kernel/locking/lockdep.c:3753
       __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
       _raw_spin_lock+0x33/0x50 kernel/locking/spinlock.c:151
       spin_lock include/linux/spinlock.h:299 [inline]
       inet_ehash_insert+0x240/0xad0 net/ipv4/inet_hashtables.c:407
       reqsk_queue_hash_req net/ipv4/inet_connection_sock.c:753 [inline]
       inet_csk_reqsk_queue_hash_add+0x1b7/0x2a0 net/ipv4/inet_connection_sock.c:764
       dccp_v6_conn_request+0xada/0x11b0 net/dccp/ipv6.c:380
       dccp_rcv_state_process+0x51e/0x1660 net/dccp/input.c:606
       dccp_v6_do_rcv+0x213/0x350 net/dccp/ipv6.c:632
       sk_backlog_rcv include/net/sock.h:896 [inline]
       __release_sock+0x127/0x3a0 net/core/sock.c:2052
       release_sock+0xa5/0x2b0 net/core/sock.c:2539
       sock_setsockopt+0x60f/0x1e40 net/core/sock.c:1016
       SYSC_setsockopt net/socket.c:1782 [inline]
       SyS_setsockopt+0x2fb/0x3a0 net/socket.c:1765
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      RIP: 0033:0x4458b9
      RSP: 002b:00007fe8b26c2b58 EFLAGS: 00000292 ORIG_RAX: 0000000000000036
      RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00000000004458b9
      RDX: 000000000000001a RSI: 0000000000000001 RDI: 0000000000000006
      RBP: 00000000006e2110 R08: 0000000000000010 R09: 0000000000000000
      R10: 00000000208c3000 R11: 0000000000000292 R12: 0000000000708000
      R13: 0000000020000000 R14: 0000000000001000 R15: 0000000000000000
      
      Fixes: 5413d1ba ("net: do not block BH while processing socket backlog")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da2da823
    • Ido Schimmel's avatar
      mlxsw: spectrum_router: Avoid potential packets loss · 8f05976c
      Ido Schimmel authored
      [ Upstream commit f7df4923 ]
      
      When the structure of the LPM tree changes (f.e., due to the addition of
      a new prefix), we unbind the old tree and then bind the new one. This
      may result in temporary packet loss.
      
      Instead, overwrite the old binding with the new one.
      
      Fixes: 6b75c480 ("mlxsw: spectrum_router: Add virtual router management")
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8f05976c
    • Jakub Kicinski's avatar
      geneve: lock RCU on TX path · 40f9f783
      Jakub Kicinski authored
      [ Upstream commit a717e3f7 ]
      
      There is no guarantees that callers of the TX path will hold
      the RCU lock.  Grab it explicitly.
      
      Fixes: fceb9c3e ("geneve: avoid using stale geneve socket.")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40f9f783
    • Jakub Kicinski's avatar
      vxlan: lock RCU on TX path · d6705c8c
      Jakub Kicinski authored
      [ Upstream commit 56de859e ]
      
      There is no guarantees that callers of the TX path will hold
      the RCU lock.  Grab it explicitly.
      
      Fixes: c6fcc4fc ("vxlan: avoid using stale vxlan socket.")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6705c8c
    • Paul Hüber's avatar
      l2tp: avoid use-after-free caused by l2tp_ip_backlog_recv · 4c94beba
      Paul Hüber authored
      [ Upstream commit 51fb60eb ]
      
      l2tp_ip_backlog_recv may not return -1 if the packet gets dropped.
      The return value is passed up to ip_local_deliver_finish, which treats
      negative values as an IP protocol number for resubmission.
      Signed-off-by: default avatarPaul Hüber <phueber@kernsp.in>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c94beba
    • Roman Mashak's avatar
      net sched actions: decrement module reference count after table flush. · 639fdd96
      Roman Mashak authored
      [ Upstream commit edb9d1bf ]
      
      When tc actions are loaded as a module and no actions have been installed,
      flushing them would result in actions removed from the memory, but modules
      reference count not being decremented, so that the modules would not be
      unloaded.
      
      Following is example with GACT action:
      
      % sudo modprobe act_gact
      % lsmod
      Module                  Size  Used by
      act_gact               16384  0
      %
      % sudo tc actions ls action gact
      %
      % sudo tc actions flush action gact
      % lsmod
      Module                  Size  Used by
      act_gact               16384  1
      % sudo tc actions flush action gact
      % lsmod
      Module                  Size  Used by
      act_gact               16384  2
      % sudo rmmod act_gact
      rmmod: ERROR: Module act_gact is in use
      ....
      
      After the fix:
      % lsmod
      Module                  Size  Used by
      act_gact               16384  0
      %
      % sudo tc actions add action pass index 1
      % sudo tc actions add action pass index 2
      % sudo tc actions add action pass index 3
      % lsmod
      Module                  Size  Used by
      act_gact               16384  3
      %
      % sudo tc actions flush action gact
      % lsmod
      Module                  Size  Used by
      act_gact               16384  0
      %
      % sudo tc actions flush action gact
      % lsmod
      Module                  Size  Used by
      act_gact               16384  0
      % sudo rmmod act_gact
      % lsmod
      Module                  Size  Used by
      %
      
      Fixes: f97017cd ("net-sched: Fix actions flushing")
      Signed-off-by: default avatarRoman Mashak <mrv@mojatatu.com>
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.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>
      639fdd96
    • Xin Long's avatar
      sctp: set sin_port for addr param when checking duplicate address · 467bec36
      Xin Long authored
      [ Upstream commit 2e3ce5bc ]
      
      Commit b8607805 ("sctp: not copying duplicate addrs to the assoc's
      bind address list") tried to check for duplicate address before copying
      to asoc's bind_addr list from global addr list.
      
      But all the addrs' sin_ports in global addr list are 0 while the addrs'
      sin_ports are bp->port in asoc's bind_addr list. It means even if it's
      a duplicate address, af->cmp_addr will still return 0 as the their
      sin_ports are different.
      
      This patch is to fix it by setting the sin_port for addr param with
      bp->port before comparing the addrs.
      
      Fixes: b8607805 ("sctp: not copying duplicate addrs to the assoc's bind address list")
      Reported-by: default avatarWei Chen <weichen@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      467bec36
    • Julian Anastasov's avatar
      ipv4: mask tos for input route · 91f4f5bf
      Julian Anastasov authored
      [ Upstream commit 6e28099d ]
      
      Restore the lost masking of TOS in input route code to
      allow ip rules to match it properly.
      
      Problem [1] noticed by Shmulik Ladkani <shmulik.ladkani@gmail.com>
      
      [1] http://marc.info/?t=137331755300040&r=1&w=2
      
      Fixes: 89aef892 ("ipv4: Delete routing cache.")
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      91f4f5bf
    • Julian Anastasov's avatar
      ipv4: add missing initialization for flowi4_uid · 0a33d62a
      Julian Anastasov authored
      [ Upstream commit 8bcfd092 ]
      
      Avoid matching of random stack value for uid when rules
      are looked up on input route or when RP filter is used.
      Problem should affect only setups that use ip rules with
      uid range.
      
      Fixes: 622ec2c9 ("net: core: add UID to flows, rules, and routes")
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a33d62a
    • Brian Russell's avatar
      vxlan: don't allow overwrite of config src addr · 2b5a48d6
      Brian Russell authored
      [ Upstream commit 1158632b ]
      
      When using IPv6 transport and a default dst, a pointer to the configured
      source address is passed into the route lookup. If no source address is
      configured, then the value is overwritten.
      
      IPv6 route lookup ignores egress ifindex match if the source address is set,
      so if egress ifindex match is desired, the source address must be passed
      as any. The overwrite breaks this for subsequent lookups.
      
      Avoid this by copying the configured address to an existing stack variable
      and pass a pointer to that instead.
      
      Fixes: 272d96a5 ("net: vxlan: lwt: Use source ip address during route lookup.")
      Signed-off-by: default avatarBrian Russell <brussell@brocade.com>
      Acked-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b5a48d6
    • David Forster's avatar
      vti6: return GRE_KEY for vti6 · fef3f97a
      David Forster authored
      [ Upstream commit 7dcdf941 ]
      
      Align vti6 with vti by returning GRE_KEY flag. This enables iproute2
      to display tunnel keys on "ip -6 tunnel show"
      Signed-off-by: default avatarDavid Forster <dforster@brocade.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fef3f97a
    • Matthias Schiffer's avatar
      vxlan: correctly validate VXLAN ID against VXLAN_N_VID · 36ec2150
      Matthias Schiffer authored
      [ Upstream commit 4e37d691 ]
      
      The incorrect check caused an off-by-one error: the maximum VID 0xffffff
      was unusable.
      
      Fixes: d342894c ("vxlan: virtual extensible lan")
      Signed-off-by: default avatarMatthias Schiffer <mschiffer@universe-factory.net>
      Acked-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36ec2150
    • Marcelo Ricardo Leitner's avatar
      sctp: deny peeloff operation on asocs with threads sleeping on it · f4487753
      Marcelo Ricardo Leitner authored
      [ Upstream commit dfcb9f4f ]
      
      commit 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
      attempted to avoid a BUG_ON call when the association being used for a
      sendmsg() is blocked waiting for more sndbuf and another thread did a
      peeloff operation on such asoc, moving it to another socket.
      
      As Ben Hutchings noticed, then in such case it would return without
      locking back the socket and would cause two unlocks in a row.
      
      Further analysis also revealed that it could allow a double free if the
      application managed to peeloff the asoc that is created during the
      sendmsg call, because then sctp_sendmsg() would try to free the asoc
      that was created only for that call.
      
      This patch takes another approach. It will deny the peeloff operation
      if there is a thread sleeping on the asoc, so this situation doesn't
      exist anymore. This avoids the issues described above and also honors
      the syscalls that are already being handled (it can be multiple sendmsg
      calls).
      
      Joint work with Xin Long.
      
      Fixes: 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf")
      Cc: Alexander Popov <alex.popov@linux.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4487753
    • Tariq Toukan's avatar
      net/mlx5e: Fix wrong CQE decompression · 55bb0dd0
      Tariq Toukan authored
      [ Upstream commit 36154be4 ]
      
      In cqe compression with striding RQ, the decompression of the CQE field
      wqe_counter was done with a wrong wraparound value.
      This caused handling cqes with a wrong pointer to wqe (rx descriptor)
      and creating SKBs with wrong data, pointing to wrong (and already consumed)
      strides/pages.
      
      The meaning of the CQE field wqe_counter in striding RQ holds the
      stride index instead of the WQE index. Hence, when decompressing
      a CQE, wqe_counter should have wrapped-around the number of strides
      in a single multi-packet WQE.
      
      We dropped this wrap-around mask at all in CQE decompression of striding
      RQ. It is not needed as in such cases the CQE compression session would
      break because of different value of wqe_id field, starting a new
      compression session.
      
      Tested:
       ethtool -K ethxx lro off/on
       ethtool --set-priv-flags ethxx rx_cqe_compress on
       super_netperf 16 {ipv4,ipv6} -t TCP_STREAM -m 50 -D
       verified no csum errors and no page refcount issues.
      
      Fixes: 7219ab34 ("net/mlx5e: CQE compression")
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Reported-by: default avatarTom Herbert <tom@herbertland.com>
      Cc: kernel-team@fb.com
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      55bb0dd0
    • Saeed Mahameed's avatar
      net/mlx5e: Update MPWQE stride size when modifying CQE compress state · c0dc4855
      Saeed Mahameed authored
      [ Upstream commit 6dc4b54e ]
      
      When the admin enables/disables cqe compression, updating
      mpwqe stride size is required:
          CQE compress ON  ==> stride size = 256B
          CQE compress OFF ==> stride size = 64B
      
      This is already done on driver load via mlx5e_set_rq_type_params, all we
      need is just to call it on arbitrary admin changes of cqe compression
      state via priv flags or when changing timestamping state
      (as it is mutually exclusive with cqe compression).
      
      This bug introduces no functional damage, it only makes cqe compression
      occur less often, since in ConnectX4-LX CQE compression is performed
      only on packets smaller than stride size.
      
      Tested:
       ethtool --set-priv-flags ethxx rx_cqe_compress on
       pktgen with  64 < pkt size < 256 and netperf TCP_STREAM (IPv4/IPv6)
       verify `ethtool -S ethxx | grep compress` are advancing more often
       (rapidly)
      
      Fixes: 7219ab34 ("net/mlx5e: CQE compression")
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Cc: kernel-team@fb.com
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0dc4855
    • Tariq Toukan's avatar
      net/mlx5e: Fix broken CQE compression initialization · c34c1786
      Tariq Toukan authored
      [ Upstream commit b0d4660b ]
      
      Some of RQ type parameters are derived from CQE compression state flag,
      CQE compression flag was initialized only after RQ type parameters
      setup. This leads to load RQ with stride size smaller than what we
      want for when CQE compression is on.
      
      This bug introduces no functional damage, it only makes CQE compression
      occur less often, since in ConnectX4-LX CQE compression is performed
      only on packets smaller than stride size.
      
      Fix this by marking default status of CQE compression in PFLAG prior to
      calling mlx5e_set_rq_priv_params(), as it inits some fields based on it.
      
      Tested:
       load driver on systems where rx CQE compress will be on (MH)
       pktgen with  64 < pkt size < 256 and netperf TCP_STREAM (IPv4/IPv6)
       verify `ethtool -S ethxx | grep compress` are advancing more often
       (rapidly)
      
      Fixes: 2fc4bfb7 ("net/mlx5e: Dynamic RQ type infrastructure")
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Cc: kernel-team@fb.com
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c34c1786
    • Tariq Toukan's avatar
      net/mlx5e: Do not reduce LRO WQE size when not using build_skb · 850a1bfb
      Tariq Toukan authored
      [ Upstream commit 4078e637 ]
      
      When rq_type is Striding RQ, no room of SKB_RESERVE is needed
      as SKB allocation is not done via build_skb.
      
      Fixes: e4b85508 ("net/mlx5e: Slightly reduce hardware LRO size")
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      850a1bfb
    • Saeed Mahameed's avatar
      net/mlx5e: Register/unregister vport representors on interface attach/detach · 96b457b8
      Saeed Mahameed authored
      [ Upstream commit 6f08a22c ]
      
      Currently vport representors are added only on driver load and removed on
      driver unload.  Apparently we forgot to handle them when we added the
      seamless reset flow feature.  This caused to leave the representors
      netdevs alive and active with open HW resources on pci shutdown and on
      error reset flows.
      
      To overcome this we move their handling to interface attach/detach, so
      they would be cleaned up on shutdown and recreated on reset flows.
      
      Fixes: 26e59d80 ("net/mlx5e: Implement mlx5e interface attach/detach callbacks")
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Reviewed-by: default avatarHadar Hen Zion <hadarh@mellanox.com>
      Reviewed-by: default avatarRoi Dayan <roid@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96b457b8
  2. 18 Mar, 2017 11 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.10.4 · 8ea22fb3
      Greg Kroah-Hartman authored
      8ea22fb3
    • Kamal Heib's avatar
      IB/mlx5: Verify that Q counters are supported · 42b16fff
      Kamal Heib authored
      commit 45bded2c upstream.
      
      Make sure that the Q counters are supported by the FW before trying
      to allocate/deallocte them, this will avoid driver load failure when
      they aren't supported by the FW.
      
      Fixes: 0837e86a ('IB/mlx5: Add per port counters')
      Signed-off-by: default avatarKamal Heib <kamalh@mellanox.com>
      Reviewed-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leon@kernel.org>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      42b16fff
    • Theodore Ts'o's avatar
      ext4: don't BUG when truncating encrypted inodes on the orphan list · dc37bb8d
      Theodore Ts'o authored
      commit 0d06863f upstream.
      
      Fix a BUG when the kernel tries to mount a file system constructed as
      follows:
      
      echo foo > foo.txt
      mke2fs -Fq -t ext4 -O encrypt foo.img 100
      debugfs -w foo.img << EOF
      write foo.txt a
      set_inode_field a i_flags 0x80800
      set_super_value s_last_orphan 12
      quit
      EOF
      
      root@kvm-xfstests:~# mount -o loop foo.img /mnt
      [  160.238770] ------------[ cut here ]------------
      [  160.240106] kernel BUG at /usr/projects/linux/ext4/fs/ext4/inode.c:3874!
      [  160.240106] invalid opcode: 0000 [#1] SMP
      [  160.240106] Modules linked in:
      [  160.240106] CPU: 0 PID: 2547 Comm: mount Tainted: G        W       4.10.0-rc3-00034-gcdd33b941b67 #227
      [  160.240106] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1 04/01/2014
      [  160.240106] task: f4518000 task.stack: f47b6000
      [  160.240106] EIP: ext4_block_zero_page_range+0x1a7/0x2b4
      [  160.240106] EFLAGS: 00010246 CPU: 0
      [  160.240106] EAX: 00000001 EBX: f7be4b50 ECX: f47b7dc0 EDX: 00000007
      [  160.240106] ESI: f43b05a8 EDI: f43babec EBP: f47b7dd0 ESP: f47b7dac
      [  160.240106]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  160.240106] CR0: 80050033 CR2: bfd85b08 CR3: 34a00680 CR4: 000006f0
      [  160.240106] Call Trace:
      [  160.240106]  ext4_truncate+0x1e9/0x3e5
      [  160.240106]  ext4_fill_super+0x286f/0x2b1e
      [  160.240106]  ? set_blocksize+0x2e/0x7e
      [  160.240106]  mount_bdev+0x114/0x15f
      [  160.240106]  ext4_mount+0x15/0x17
      [  160.240106]  ? ext4_calculate_overhead+0x39d/0x39d
      [  160.240106]  mount_fs+0x58/0x115
      [  160.240106]  vfs_kern_mount+0x4b/0xae
      [  160.240106]  do_mount+0x671/0x8c3
      [  160.240106]  ? _copy_from_user+0x70/0x83
      [  160.240106]  ? strndup_user+0x31/0x46
      [  160.240106]  SyS_mount+0x57/0x7b
      [  160.240106]  do_int80_syscall_32+0x4f/0x61
      [  160.240106]  entry_INT80_32+0x2f/0x2f
      [  160.240106] EIP: 0xb76b919e
      [  160.240106] EFLAGS: 00000246 CPU: 0
      [  160.240106] EAX: ffffffda EBX: 08053838 ECX: 08052188 EDX: 080537e8
      [  160.240106] ESI: c0ed0000 EDI: 00000000 EBP: 080537e8 ESP: bfa13660
      [  160.240106]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
      [  160.240106] Code: 59 8b 00 a8 01 0f 84 09 01 00 00 8b 07 66 25 00 f0 66 3d 00 80 75 61 89 f8 e8 3e e2 ff ff 84 c0 74 56 83 bf 48 02 00 00 00 75 02 <0f> 0b 81 7d e8 00 10 00 00 74 02 0f 0b 8b 43 04 8b 53 08 31 c9
      [  160.240106] EIP: ext4_block_zero_page_range+0x1a7/0x2b4 SS:ESP: 0068:f47b7dac
      [  160.317241] ---[ end trace d6a773a375c810a5 ]---
      
      The problem is that when the kernel tries to truncate an inode in
      ext4_truncate(), it tries to clear any on-disk data beyond i_size.
      Without the encryption key, it can't do that, and so it triggers a
      BUG.
      
      E2fsck does *not* provide this service, and in practice most file
      systems have their orphan list processed by e2fsck, so to avoid
      crashing, this patch skips this step if we don't have access to the
      encryption key (which is the case when processing the orphan list; in
      all other cases, we will have the encryption key, or the kernel
      wouldn't have allowed the file to be opened).
      
      An open question is whether the fact that e2fsck isn't clearing the
      bytes beyond i_size causing problems --- and if we've lived with it
      not doing it for so long, can we drop this from the kernel replay of
      the orphan list in all cases (not just when we don't have the key for
      encrypted inodes).
      
      Addresses-Google-Bug: #35209576
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc37bb8d
    • Sean Young's avatar
      rc: raw decoder for keymap protocol is not loaded on register · 1cda2908
      Sean Young authored
      commit 41380868 upstream.
      
      When the protocol is set via the sysfs protocols attribute, the
      decoder is loaded. However, when it is not when a device is first
      plugged in or registered.
      
      Fixes: acc1c3c6 ("[media] media: rc: load decoder modules on-demand")
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      1cda2908
    • Mikulas Patocka's avatar
      dm: flush queued bios when process blocks to avoid deadlock · 22fc2f9e
      Mikulas Patocka authored
      commit d67a5f4b upstream.
      
      Commit df2cb6da ("block: Avoid deadlocks with bio allocation by
      stacking drivers") created a workqueue for every bio set and code
      in bio_alloc_bioset() that tries to resolve some low-memory deadlocks
      by redirecting bios queued on current->bio_list to the workqueue if the
      system is low on memory.  However other deadlocks (see below **) may
      happen, without any low memory condition, because generic_make_request
      is queuing bios to current->bio_list (rather than submitting them).
      
      ** the related dm-snapshot deadlock is detailed here:
      https://www.redhat.com/archives/dm-devel/2016-July/msg00065.html
      
      Fix this deadlock by redirecting any bios on current->bio_list to the
      bio_set's rescue workqueue on every schedule() call.  Consequently,
      when the process blocks on a mutex, the bios queued on
      current->bio_list are dispatched to independent workqueus and they can
      complete without waiting for the mutex to be available.
      
      The structure blk_plug contains an entry cb_list and this list can contain
      arbitrary callback functions that are called when the process blocks.
      To implement this fix DM (ab)uses the onstack plug's cb_list interface
      to get its flush_current_bio_list() called at schedule() time.
      
      This fixes the snapshot deadlock - if the map method blocks,
      flush_current_bio_list() will be called and it redirects bios waiting
      on current->bio_list to appropriate workqueues.
      
      Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1267650
      Depends-on: df2cb6da ("block: Avoid deadlocks with bio allocation by stacking drivers")
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      22fc2f9e
    • Sean Young's avatar
      serial_ir: ensure we're ready to receive interrupts · 2030aedc
      Sean Young authored
      commit 0265634e upstream.
      
      When the interrupt requested with devm_request_irq(), serial_ir.rcdev
      is still null so will cause null deference if the irq handler is called
      early on.
      
      Also ensure that timeout_timer is setup.
      
      Link: http://lkml.kernel.org/r/CA+55aFxsh2uF8gi5sN_guY3Z+tiLv7LpJYKBw+y8vqLzp+TsnQ@mail.gmail.com
      
      [mchehab@s-opensource.com: moved serial_ir_probe() back to its original place]
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2030aedc
    • Takashi Iwai's avatar
      drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env var · 81383a00
      Takashi Iwai authored
      commit d8e9b2b9 upstream.
      
      send_display_send_uevent() sends two environment variable, and the
      first one GVT_DISPLAY_READY is set including a new line at the end of
      the string; that is obviously superfluous and wrong -- at least, it
      *looks* so when you only read the code.
      
      However, it doesn't appear in the actual output by a (supposedly
      unexpected) trick.  The code uses snprintf() and truncates the string
      in size 20 bytes.  This makes the string as GVT_DISPLAY_READY=0 or
      ...=1 including the trailing NUL-letter.  That is, the '\n' found in
      the format string is always cut off as a result.
      
      Although the code gives the correct result, it is confusing.  This
      patch addresses it, just removing the superfluous '\n' from the format
      string for avoiding further confusion.  If the argument "ready" were
      not a  bool, the size 20 should be corrected as well.  But it's a
      bool, so we can leave the magic number 20 as is for now.
      
      FWIW, the bug was spotted by a new GCC7 warning:
        drivers/gpu/drm/i915/gvt/handlers.c: In function 'pvinfo_mmio_write':
        drivers/gpu/drm/i915/gvt/handlers.c:1042:34: error: 'snprintf' output truncated before the last format character [-Werror=format-truncation=]
          snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
                                          ^~~~~~~~~~~~~~~~~~~~~~~~
        drivers/gpu/drm/i915/gvt/handlers.c:1042:2: note: 'snprintf' output 21 bytes into a destination of size 20
          snprintf(display_ready_str, 20, "GVT_DISPLAY_READY=%d\n", ready);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Fixes: 04d348ae ("drm/i915/gvt: vGPU display virtualization")
      Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1025903Reported-by: default avatarRichard Biener <rguenther@suse.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81383a00
    • Jintack Lim's avatar
      KVM: arm/arm64: Let vcpu thread modify its own active state · 523379cd
      Jintack Lim authored
      commit 370a0ec1 upstream.
      
      Currently, if a vcpu thread tries to change the active state of an
      interrupt which is already on the same vcpu's AP list, it will loop
      forever. Since the VGIC mmio handler is called after a vcpu has
      already synced back the LR state to the struct vgic_irq, we can just
      let it proceed safely.
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarJintack Lim <jintack@cs.columbia.edu>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      523379cd
    • Janosch Frank's avatar
      KVM: s390: Fix guest migration for huge guests resulting in panic · 1f9175b9
      Janosch Frank authored
      commit 2e4d8800 upstream.
      
      While we can technically not run huge page guests right now, we can
      setup a guest with huge pages. Trying to migrate it will trigger a
      VM_BUG_ON and, if the kernel is not configured to panic on a BUG, it
      will happily try to work on non-existing page table entries.
      
      With this patch, we always return "dirty" if we encounter a large page
      when migrating. This at least fixes the immediate problem until we
      have proper handling for both kind of pages.
      
      Fixes: 15f36ebd ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
      Signed-off-by: default avatarJanosch Frank <frankja@linux.vnet.ibm.com>
      Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f9175b9
    • Krzysztof Kozlowski's avatar
      serial: samsung: Continue to work if DMA request fails · 45dc259a
      Krzysztof Kozlowski authored
      commit f98c7bce upstream.
      
      If DMA is not available (even when configured in DeviceTree), the driver
      will fail the startup procedure thus making serial console not
      available.
      
      For example this causes boot failure on QEMU ARMv7 (Exynos4210, SMDKC210):
          [    1.302575] OF: amba_device_add() failed (-19) for /amba/pdma@12680000
          ...
          [   11.435732] samsung-uart 13800000.serial: DMA request failed
          [   72.963893] samsung-uart 13800000.serial: DMA request failed
          [   73.143361] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
      
      DMA is not necessary for serial to work, so continue with UART startup
      after emitting a warning.
      
      Fixes: 62c37eed ("serial: samsung: add dma reqest/release functions")
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      45dc259a
    • Johan Hovold's avatar
      USB: serial: io_ti: fix information leak in completion handler · 7daf817d
      Johan Hovold authored
      commit 654b404f upstream.
      
      Add missing sanity check to the bulk-in completion handler to avoid an
      integer underflow that can be triggered by a malicious device.
      
      This avoids leaking 128 kB of memory content from after the URB transfer
      buffer to user space.
      
      Fixes: 8c209e67 ("USB: make actual_length in struct urb field u32")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7daf817d