1. 18 4月, 2018 2 次提交
    • B
      sfc: check RSS is active for filter insert · 89bda97b
      Bert Kenward 提交于
      For some firmware variants - specifically 'capture packed stream' - RSS
      filters are not valid. We must check if RSS is actually active rather
      than merely enabled.
      
      Fixes: 42356d9a ("sfc: support RSS spreading of ethtool ntuple filters")
      Signed-off-by: NBert Kenward <bkenward@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89bda97b
    • T
      vlan: Fix reading memory beyond skb->tail in skb_vlan_tagged_multi · 7ce23672
      Toshiaki Makita 提交于
      Syzkaller spotted an old bug which leads to reading skb beyond tail by 4
      bytes on vlan tagged packets.
      This is caused because skb_vlan_tagged_multi() did not check
      skb_headlen.
      
      BUG: KMSAN: uninit-value in eth_type_vlan include/linux/if_vlan.h:283 [inline]
      BUG: KMSAN: uninit-value in skb_vlan_tagged_multi include/linux/if_vlan.h:656 [inline]
      BUG: KMSAN: uninit-value in vlan_features_check include/linux/if_vlan.h:672 [inline]
      BUG: KMSAN: uninit-value in dflt_features_check net/core/dev.c:2949 [inline]
      BUG: KMSAN: uninit-value in netif_skb_features+0xd1b/0xdc0 net/core/dev.c:3009
      CPU: 1 PID: 3582 Comm: syzkaller435149 Not tainted 4.16.0+ #82
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:17 [inline]
        dump_stack+0x185/0x1d0 lib/dump_stack.c:53
        kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
        __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
        eth_type_vlan include/linux/if_vlan.h:283 [inline]
        skb_vlan_tagged_multi include/linux/if_vlan.h:656 [inline]
        vlan_features_check include/linux/if_vlan.h:672 [inline]
        dflt_features_check net/core/dev.c:2949 [inline]
        netif_skb_features+0xd1b/0xdc0 net/core/dev.c:3009
        validate_xmit_skb+0x89/0x1320 net/core/dev.c:3084
        __dev_queue_xmit+0x1cb2/0x2b60 net/core/dev.c:3549
        dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
        packet_snd net/packet/af_packet.c:2944 [inline]
        packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg net/socket.c:640 [inline]
        sock_write_iter+0x3b9/0x470 net/socket.c:909
        do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
        do_iter_write+0x30d/0xd40 fs/read_write.c:932
        vfs_writev fs/read_write.c:977 [inline]
        do_writev+0x3c9/0x830 fs/read_write.c:1012
        SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
        SyS_writev+0x56/0x80 fs/read_write.c:1082
        do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x43ffa9
      RSP: 002b:00007fff2cff3948 EFLAGS: 00000217 ORIG_RAX: 0000000000000014
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043ffa9
      RDX: 0000000000000001 RSI: 0000000020000080 RDI: 0000000000000003
      RBP: 00000000006cb018 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000217 R12: 00000000004018d0
      R13: 0000000000401960 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was created at:
        kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
        kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
        kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
        kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
        slab_post_alloc_hook mm/slab.h:445 [inline]
        slab_alloc_node mm/slub.c:2737 [inline]
        __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
        __kmalloc_reserve net/core/skbuff.c:138 [inline]
        __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
        alloc_skb include/linux/skbuff.h:984 [inline]
        alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
        sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
        packet_alloc_skb net/packet/af_packet.c:2803 [inline]
        packet_snd net/packet/af_packet.c:2894 [inline]
        packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg net/socket.c:640 [inline]
        sock_write_iter+0x3b9/0x470 net/socket.c:909
        do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
        do_iter_write+0x30d/0xd40 fs/read_write.c:932
        vfs_writev fs/read_write.c:977 [inline]
        do_writev+0x3c9/0x830 fs/read_write.c:1012
        SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
        SyS_writev+0x56/0x80 fs/read_write.c:1082
        do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      Fixes: 58e998c6 ("offloading: Force software GSO for multiple vlan tags.")
      Reported-and-tested-by: syzbot+0bbe42c764feafa82c5a@syzkaller.appspotmail.com
      Signed-off-by: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ce23672
  2. 17 4月, 2018 7 次提交
  3. 16 4月, 2018 7 次提交
    • E
      net: af_packet: fix race in PACKET_{R|T}X_RING · 5171b37d
      Eric Dumazet 提交于
      In order to remove the race caught by syzbot [1], we need
      to lock the socket before using po->tp_version as this could
      change under us otherwise.
      
      This means lock_sock() and release_sock() must be done by
      packet_set_ring() callers.
      
      [1] :
      BUG: KMSAN: uninit-value in packet_set_ring+0x1254/0x3870 net/packet/af_packet.c:4249
      CPU: 0 PID: 20195 Comm: syzkaller707632 Not tainted 4.16.0+ #83
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x185/0x1d0 lib/dump_stack.c:53
       kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
       __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
       packet_set_ring+0x1254/0x3870 net/packet/af_packet.c:4249
       packet_setsockopt+0x12c6/0x5a90 net/packet/af_packet.c:3662
       SYSC_setsockopt+0x4b8/0x570 net/socket.c:1849
       SyS_setsockopt+0x76/0xa0 net/socket.c:1828
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x449099
      RSP: 002b:00007f42b5307ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
      RAX: ffffffffffffffda RBX: 000000000070003c RCX: 0000000000449099
      RDX: 0000000000000005 RSI: 0000000000000107 RDI: 0000000000000003
      RBP: 0000000000700038 R08: 000000000000001c R09: 0000000000000000
      R10: 00000000200000c0 R11: 0000000000000246 R12: 0000000000000000
      R13: 000000000080eecf R14: 00007f42b53089c0 R15: 0000000000000001
      
      Local variable description: ----req_u@packet_setsockopt
      Variable was created at:
       packet_setsockopt+0x13f/0x5a90 net/packet/af_packet.c:3612
       SYSC_setsockopt+0x4b8/0x570 net/socket.c:1849
      
      Fixes: f6fb8f10 ("af-packet: TPACKET_V3 flexible buffer implementation.")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5171b37d
    • T
      ibmvnic: Clear pending interrupt after device reset · f23e0643
      Thomas Falcon 提交于
      Due to a firmware bug, the hypervisor can send an interrupt to a
      transmit or receive queue just prior to a partition migration, not
      allowing the device enough time to handle it and send an EOI. When
      the partition migrates, the interrupt is lost but an "EOI-pending"
      flag for the interrupt line is still set in firmware. No further
      interrupts will be sent until that flag is cleared, effectively
      freezing that queue. To workaround this, the driver will disable the
      hardware interrupt and send an H_EOI signal prior to re-enabling it.
      This will flush the pending EOI and allow the driver to continue
      operation.
      Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f23e0643
    • S
      tcp: clear tp->packets_out when purging write queue · bffd168c
      Soheil Hassas Yeganeh 提交于
      Clear tp->packets_out when purging the write queue, otherwise
      tcp_rearm_rto() mistakenly assumes TCP write queue is not empty.
      This results in NULL pointer dereference.
      
      Also, remove the redundant `tp->packets_out = 0` from
      tcp_disconnect(), since tcp_disconnect() calls
      tcp_write_queue_purge().
      
      Fixes: a27fd7a8 (tcp: purge write queue upon RST)
      Reported-by: NSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Reported-by: NSami Farin <hvtaifwkbgefbaei@gmail.com>
      Tested-by: NSami Farin <hvtaifwkbgefbaei@gmail.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bffd168c
    • P
      team: avoid adding twice the same option to the event list · 4fb0534f
      Paolo Abeni 提交于
      When parsing the options provided by the user space,
      team_nl_cmd_options_set() insert them in a temporary list to send
      multiple events with a single message.
      While each option's attribute is correctly validated, the code does
      not check for duplicate entries before inserting into the event
      list.
      
      Exploiting the above, the syzbot was able to trigger the following
      splat:
      
      kernel BUG at lib/list_debug.c:31!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
          (ftrace buffer empty)
      Modules linked in:
      CPU: 0 PID: 4466 Comm: syzkaller556835 Not tainted 4.16.0+ #17
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__list_add_valid+0xaa/0xb0 lib/list_debug.c:29
      RSP: 0018:ffff8801b04bf248 EFLAGS: 00010286
      RAX: 0000000000000058 RBX: ffff8801c8fc7a90 RCX: 0000000000000000
      RDX: 0000000000000058 RSI: ffffffff815fbf41 RDI: ffffed0036097e3f
      RBP: ffff8801b04bf260 R08: ffff8801b0b2a700 R09: ffffed003b604f90
      R10: ffffed003b604f90 R11: ffff8801db027c87 R12: ffff8801c8fc7a90
      R13: ffff8801c8fc7a90 R14: dffffc0000000000 R15: 0000000000000000
      FS:  0000000000b98880(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000000043fc30 CR3: 00000001afe8e000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        __list_add include/linux/list.h:60 [inline]
        list_add include/linux/list.h:79 [inline]
        team_nl_cmd_options_set+0x9ff/0x12b0 drivers/net/team/team.c:2571
        genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
        genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
        netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
        genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
        netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
        netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
        netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
        sock_sendmsg_nosec net/socket.c:629 [inline]
        sock_sendmsg+0xd5/0x120 net/socket.c:639
        ___sys_sendmsg+0x805/0x940 net/socket.c:2117
        __sys_sendmsg+0x115/0x270 net/socket.c:2155
        SYSC_sendmsg net/socket.c:2164 [inline]
        SyS_sendmsg+0x29/0x30 net/socket.c:2162
        do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x42/0xb7
      RIP: 0033:0x4458b9
      RSP: 002b:00007ffd1d4a7278 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 000000000000001b RCX: 00000000004458b9
      RDX: 0000000000000010 RSI: 0000000020000d00 RDI: 0000000000000004
      RBP: 00000000004a74ed R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000213 R12: 00007ffd1d4a7348
      R13: 0000000000402a60 R14: 0000000000000000 R15: 0000000000000000
      Code: 75 e8 eb a9 48 89 f7 48 89 75 e8 e8 d1 85 7b fe 48 8b 75 e8 eb bb 48
      89 f2 48 89 d9 4c 89 e6 48 c7 c7 a0 84 d8 87 e8 ea 67 28 fe <0f> 0b 0f 1f
      40 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5 41
      RIP: __list_add_valid+0xaa/0xb0 lib/list_debug.c:29 RSP: ffff8801b04bf248
      
      This changeset addresses the avoiding list_add() if the current
      option is already present in the event list.
      
      Reported-and-tested-by: syzbot+4d4af685432dc0e56c91@syzkaller.appspotmail.com
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Fixes: 2fcdb2c9 ("team: allow to send multiple set events in one message")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4fb0534f
    • M
      net: mvpp2: Fix TCAM filter reserved range · 982e0500
      Maxime Chevallier 提交于
      Marvell's PPv2 controller has a Packet Header parser, which uses a
      fixed-size TCAM array of filter entries.
      
      The mvpp2 driver reserves some ranges among the 256 TCAM entries to
      perform MAC and VID filtering. The rest of the TCAM ids are freely usable
      for other features, such as IPv4 proto matching.
      
      This commit fixes the MVPP2_PE_LAST_FREE_TID define that sets the end of
      the "free range", which included the MAC range. This could therefore allow
      some other features to use entries dedicated to MAC filtering,
      lowering the number of unicast/multicast addresses that could be allowed
      before switching to promiscuous mode.
      
      Fixes: 10fea26c ("net: mvpp2: Add support for unicast filtering")
      Signed-off-by: NMaxime Chevallier <maxime.chevallier@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      982e0500
    • D
      Revert "macsec: missing dev_put() on error in macsec_newlink()" · bd28899d
      Dan Carpenter 提交于
      This patch is just wrong, sorry.  I was trying to fix a static checker
      warning and misread the code.  The reference taken in macsec_newlink()
      is released in macsec_free_netdev() when the netdevice is destroyed.
      
      This reverts commit 5dcd8400.
      Reported-by: NLaura Abbott <labbott@redhat.com>
      Fixes: 5dcd8400 ("macsec: missing dev_put() on error in macsec_newlink()")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: NSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd28899d
    • W
      filter.txt: update 'tools/net/' to 'tools/bpf/' · c246fd33
      Wang Sheng-Hui 提交于
      The tools are located at tootls/bpf/ instead of tools/net/.
      Update the filter.txt doc.
      Signed-off-by: NWang Sheng-Hui <shhuiw@foxmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c246fd33
  4. 15 4月, 2018 4 次提交
    • D
      Merge branch 'sfc-ARFS-fixes' · d6606bcc
      David S. Miller 提交于
      Edward Cree says:
      
      ====================
      sfc: ARFS fixes
      
      Three issues introduced by my recent asynchronous filter handling changes:
      1. The old filter_rfs_insert would replace a matching filter of equal
         priority; we need to pass the appropriate argument to filter_insert to
         make it do the same.
      2. We're lying to the kernel with our return value from ndo_rx_flow_steer,
         so we need to lie consistently when calling rps_may_expire_flow.  This
         is only a partial fix, as the lie still prevents us from steering
         multiple flows with the same ID to different queues; a proper fix that
         stops us lying at all will hopefully follow later.
      3. It's possible to cause the kernel to hammer ndo_rx_flow_steer very
         hard, so make sure we don't build up too huge a backlog of workitems.
      
      Possibly it would be better to fix #3 on the kernel side; I have a patch
       which I think does that but it's not a regression in 4.17 so isn't 'net'
       material.
      There's also the issue that we come up in the bad configuration that
       triggers #3 by default, but that too is a problem for another time.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6606bcc
    • E
      sfc: limit ARFS workitems in flight per channel · f993740e
      Edward Cree 提交于
      A misconfigured system (e.g. with all interrupts affinitised to all CPUs)
       may produce a storm of ARFS steering events.  With the existing sfc ARFS
       implementation, that could create a backlog of workitems that grinds the
       system to a halt.  To prevent this, limit the number of workitems that
       may be in flight for a given SFC device to 8 (EFX_RPS_MAX_IN_FLIGHT), and
       return EBUSY from our ndo_rx_flow_steer method if the limit is reached.
      Given this limit, also store the workitems in an array of slots within the
       struct efx_nic, rather than dynamically allocating for each request.
      The limit should not negatively impact performance, because it is only
       likely to be hit in cases where ARFS will be ineffective anyway.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f993740e
    • E
      sfc: pass the correctly bogus filter_id to rps_may_expire_flow() · a7f80189
      Edward Cree 提交于
      When we inserted an ARFS filter for ndo_rx_flow_steer(), we didn't know
       what the filter ID would be, so we just returned 0.  Thus, we must also
       pass 0 as the filter ID when calling rps_may_expire_flow() for it, and
       rely on the flow_id to identify what we're talking about.
      
      Fixes: 3af0f342 ("sfc: replace asynchronous filter operations")
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a7f80189
    • E
      sfc: insert ARFS filters with replace_equal=true · 494bef4c
      Edward Cree 提交于
      Necessary to allow redirecting a flow when the application moves.
      
      Fixes: 3af0f342 ("sfc: replace asynchronous filter operations")
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      494bef4c
  5. 14 4月, 2018 4 次提交
  6. 13 4月, 2018 16 次提交
    • J
      virtio-net: add missing virtqueue kick when flushing packets · 9267c430
      Jason Wang 提交于
      We tends to batch submitting packets during XDP_TX. This requires to
      kick virtqueue after a batch, we tried to do it through
      xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So
      explicitly kick the virtqueue in this case.
      Reported-by: NKimitoshi Takahashi <ktaka@nii.ac.jp>
      Tested-by: NKimitoshi Takahashi <ktaka@nii.ac.jp>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Fixes: 186b3c99 ("virtio-net: support XDP_REDIRECT")
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9267c430
    • R
      net: dsa: mv88e6xxx: Fix receive time stamp race condition. · 22904823
      Richard Cochran 提交于
      The DSA stack passes received PTP frames to this driver via
      mv88e6xxx_port_rxtstamp() for deferred delivery.  The driver then
      queues the frame and kicks the worker thread.  The work callback reads
      out the latched receive time stamp and then works through the queue,
      delivering any non-matching frames without a time stamp.
      
      If a new frame arrives after the worker thread has read out the time
      stamp register but enters the queue before the worker finishes
      processing the queue, that frame will be delivered without a time
      stamp.
      
      This patch fixes the race by moving the queue onto a list on the stack
      before reading out the latched time stamp value.
      
      Fixes: c6fe0ad2 ("net: dsa: mv88e6xxx: add rx/tx timestamping support")
      Signed-off-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22904823
    • W
      net: fix deadlock while clearing neighbor proxy table · 53b76cdf
      Wolfgang Bumiller 提交于
      When coming from ndisc_netdev_event() in net/ipv6/ndisc.c,
      neigh_ifdown() is called with &nd_tbl, locking this while
      clearing the proxy neighbor entries when eg. deleting an
      interface. Calling the table's pndisc_destructor() with the
      lock still held, however, can cause a deadlock: When a
      multicast listener is available an IGMP packet of type
      ICMPV6_MGM_REDUCTION may be sent out. When reaching
      ip6_finish_output2(), if no neighbor entry for the target
      address is found, __neigh_create() is called with &nd_tbl,
      which it'll want to lock.
      
      Move the elements into their own list, then unlock the table
      and perform the destruction.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199289
      Fixes: 6fd6ce20 ("ipv6: Do not depend on rt->n in ip6_finish_output2().")
      Signed-off-by: NWolfgang Bumiller <w.bumiller@proxmox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      53b76cdf
    • X
      sctp: do not check port in sctp_inet6_cmp_addr · 1071ec9d
      Xin Long 提交于
      pf->cmp_addr() is called before binding a v6 address to the sock. It
      should not check ports, like in sctp_inet_cmp_addr.
      
      But sctp_inet6_cmp_addr checks the addr by invoking af(6)->cmp_addr,
      sctp_v6_cmp_addr where it also compares the ports.
      
      This would cause that setsockopt(SCTP_SOCKOPT_BINDX_ADD) could bind
      multiple duplicated IPv6 addresses after Commit 40b4f0fd ("sctp:
      lack the check for ports in sctp_v6_cmp_addr").
      
      This patch is to remove af->cmp_addr called in sctp_inet6_cmp_addr,
      but do the proper check for both v6 addrs and v4mapped addrs.
      
      v1->v2:
        - define __sctp_v6_cmp_addr to do the common address comparison
          used for both pf and af v6 cmp_addr.
      
      Fixes: 40b4f0fd ("sctp: lack the check for ports in sctp_v6_cmp_addr")
      Reported-by: NJianwen Ji <jiji@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1071ec9d
    • D
      Merge branch... · 837708a8
      David S. Miller 提交于
      Merge branch 'nfp-improve-signal-handing-on-FW-waits-and-flower-control-message-Jakub Kicinski says:
      
      ====================
      nfp: improve signal handing on FW waits and flower control message processing
      
      The first part of this set aims to improve handling of interrupted
      waits.  Patch 1 makes waiting for management FW responses
      uninterruptible while patch 2 adds a message when signal arrives
      while waiting for an NFP mutex.  We can't interrupt execution of
      FW commands so uninterruptible sleep seems reasonable there.
      Exiting a wait for a mutex should be clean and have no side affects
      so we are allowing to abort it.  Note that both waits have rather
      large timeouts (tens of seconds).
      
      Patches 3 and 4 improve flower offload operation under heavy load.
      Currently there is no cap on the number of queued FW notifications.
      Some of the notifications have to be processed from a workqueue
      which may lead to very large number of messages getting queued
      if workqueue never gets a chance to run.  Pieter puts a limit
      on number of queued messages, tries to drop some messages we ignore
      without queuing and process more important messages first.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      processing'
      837708a8
    • P
      nfp: flower: split and limit cmsg skb lists · cf2cbadc
      Pieter Jansen van Vuuren 提交于
      Introduce a second skb list for handling control messages and limit the
      number of allowed messages. Some control messages are considered more
      crucial than others, resulting in the need for a second skb list. By
      splitting the list into a separate high and low priority list we can
      ensure that messages on the high list get added to the head of the list
      that gets processed, this however has no functional impact. Previously
      there was no limit on the number of messages allowed on the queue, this
      could result in the queue growing boundlessly and eventually the host
      running out of memory.
      
      Fixes: b985f870 ("nfp: process control messages in workqueue in flower app")
      Signed-off-by: NPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf2cbadc
    • P
      nfp: flower: move route ack control messages out of the workqueue · 0b1a989e
      Pieter Jansen van Vuuren 提交于
      Previously we processed the route ack control messages in the workqueue,
      this unnecessarily loads the workqueue. We can deal with these messages
      sooner as we know we are going to drop them.
      
      Fixes: 8e6a9046 ("nfp: flower vxlan neighbour offload")
      Signed-off-by: NPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b1a989e
    • J
      nfp: print a message when mutex wait is interrupted · bc05f9bc
      Jakub Kicinski 提交于
      When waiting for an NFP mutex is interrupted print a message
      to make root causing later error messages easier.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc05f9bc
    • J
      nfp: ignore signals when communicating with management FW · 5496295a
      Jakub Kicinski 提交于
      We currently allow signals to interrupt the wait for management FW
      commands.  Exiting the wait should not cause trouble, the FW will
      just finish executing the command in the background and new commands
      will wait for the old one to finish.
      
      However, this may not be what users expect (Ctrl-C not actually stopping
      the command).  Moreover some systems routinely request link information
      with signals pending (Ubuntu 14.04 runs a landscape-sysinfo python tool
      from MOTD) worrying users with errors like these:
      
      nfp 0000:04:00.0: nfp_nsp: Error -512 waiting for code 0x0007 to start
      nfp 0000:04:00.0: nfp: reading port table failed -512
      
      Make the wait for management FW responses non-interruptible.
      
      Fixes: 1a64821c ("nfp: add support for service processor access")
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: NDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5496295a
    • J
      tipc: fix missing initializer in tipc_sendmsg() · 335b929b
      Jon Maloy 提交于
      The stack variable 'dnode' in __tipc_sendmsg() may theoretically
      end up tipc_node_get_mtu() as an unitilalized variable.
      
      We fix this by intializing the variable at declaration. We also add
      a default else clause to the two conditional ones already there, so
      that we never end up in the named function if the given address
      type is illegal.
      
      Reported-by: syzbot+b0975ce9355b347c1546@syzkaller.appspotmail.com
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      335b929b
    • D
      strparser: Fix incorrect strp->need_bytes value. · 9d0c75bf
      Doron Roberts-Kedes 提交于
      strp_data_ready resets strp->need_bytes to 0 if strp_peek_len indicates
      that the remainder of the message has been received. However,
      do_strp_work does not reset strp->need_bytes to 0. If do_strp_work
      completes a partial message, the value of strp->need_bytes will continue
      to reflect the needed bytes of the previous message, causing
      future invocations of strp_data_ready to return early if
      strp->need_bytes is less than strp_peek_len. Resetting strp->need_bytes
      to 0 in __strp_recv on handing a full message to the upper layer solves
      this problem.
      
      __strp_recv also calculates strp->need_bytes using stm->accum_len before
      stm->accum_len has been incremented by cand_len. This can cause
      strp->need_bytes to be equal to the full length of the message instead
      of the full length minus the accumulated length. This, in turn, causes
      strp_data_ready to return early, even when there is sufficient data to
      complete the partial message. Incrementing stm->accum_len before using
      it to calculate strp->need_bytes solves this problem.
      
      Found while testing net/tls_sw recv path.
      
      Fixes: 43a0c675 ("strparser: Stream parser for messages")
      Signed-off-by: NDoron Roberts-Kedes <doronrk@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d0c75bf
    • A
      selftests: net: add in_netns.sh to TEST_PROGS · 5ff9c1a3
      Anders Roxell 提交于
      Script in_netns.sh isn't installed.
      --------------------
      running psock_fanout test
      --------------------
      ./run_afpackettests: line 12: ./in_netns.sh: No such file or directory
      [FAIL]
      --------------------
      running psock_tpacket test
      --------------------
      ./run_afpackettests: line 22: ./in_netns.sh: No such file or directory
      [FAIL]
      
      In current code added in_netns.sh to be installed.
      
      Fixes: cc30c93f ("selftests/net: ignore background traffic in psock_fanout")
      Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ff9c1a3
    • D
      Merge branch 'ibmvnic-Fix-parameter-change-request-handling' · 095d3701
      David S. Miller 提交于
      Nathan Fontenot says:
      
      ====================
      ibmvnic: Fix parameter change request handling
      
      When updating parameters for the ibmvnic driver there is a possibility
      of entering an infinite loop if a return value other that a partial
      success is received from sending the login CRQ.
      
      Also, a deadlock can occur on the rtnl lock if netdev_notify_peers()
      is called during driver reset for a parameter change reset.
      
      This patch set corrects both of these issues by updating the return
      code handling in ibmvnic_login() nand gaurding against calling
      netdev_notify_peers() for parameter change requests.
      
      Updates for V2: Correct spelling mistakes in commit messages.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      095d3701
    • N
      ibmvnic: Do not notify peers on parameter change resets · ebc701b7
      Nathan Fontenot 提交于
      When attempting to change the driver parameters, such as the MTU
      value or number of queues, do not call netdev_notify_peers().
      Doing so will deadlock on the rtnl_lock.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebc701b7
    • N
      ibmvnic: Handle all login error conditions · 64d92aa2
      Nathan Fontenot 提交于
      There is a bug in handling the possible return codes from sending the
      login CRQ. The current code treats any non-success return value,
      minus failure to send the crq and a timeout waiting for a login response,
      as a need to re-send the login CRQ. This can put the drive in an
      infinite loop of trying to login when getting return values other
      that a partial success such as a return code of aborted. For these
      scenarios the login will not ever succeed at this point and the
      driver would need to be reset again.
      
      To resolve this loop trying to login is updated to only retry the
      login if the driver gets a return code of a partial success. Other
      return codes are treated as an error and the driver returns an error
      from ibmvnic_login().
      
      To avoid infinite looping in the partial success return cases, the
      number of retries is capped at the maximum number of supported
      queues. This value was chosen because the driver does a renegotiation
      of capabilities which sets the number of queues possible and allows
      the driver to attempt a login for possible value for the number
      of queues supported.
      Signed-off-by: NNathan Fontenot <nfont@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64d92aa2
    • E
      net: validate attribute sizes in neigh_dump_table() · 7dd07c14
      Eric Dumazet 提交于
      Since neigh_dump_table() calls nlmsg_parse() without giving policy
      constraints, attributes can have arbirary size that we must validate
      
      Reported by syzbot/KMSAN :
      
      BUG: KMSAN: uninit-value in neigh_master_filtered net/core/neighbour.c:2292 [inline]
      BUG: KMSAN: uninit-value in neigh_dump_table net/core/neighbour.c:2348 [inline]
      BUG: KMSAN: uninit-value in neigh_dump_info+0x1af0/0x2250 net/core/neighbour.c:2438
      CPU: 1 PID: 3575 Comm: syzkaller268891 Not tainted 4.16.0+ #83
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x185/0x1d0 lib/dump_stack.c:53
       kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
       __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
       neigh_master_filtered net/core/neighbour.c:2292 [inline]
       neigh_dump_table net/core/neighbour.c:2348 [inline]
       neigh_dump_info+0x1af0/0x2250 net/core/neighbour.c:2438
       netlink_dump+0x9ad/0x1540 net/netlink/af_netlink.c:2225
       __netlink_dump_start+0x1167/0x12a0 net/netlink/af_netlink.c:2322
       netlink_dump_start include/linux/netlink.h:214 [inline]
       rtnetlink_rcv_msg+0x1435/0x1560 net/core/rtnetlink.c:4598
       netlink_rcv_skb+0x355/0x5f0 net/netlink/af_netlink.c:2447
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:4653
       netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
       netlink_unicast+0x1672/0x1750 net/netlink/af_netlink.c:1337
       netlink_sendmsg+0x1048/0x1310 net/netlink/af_netlink.c:1900
       sock_sendmsg_nosec net/socket.c:630 [inline]
       sock_sendmsg net/socket.c:640 [inline]
       ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
       __sys_sendmsg net/socket.c:2080 [inline]
       SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
       SyS_sendmsg+0x54/0x80 net/socket.c:2087
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      RIP: 0033:0x43fed9
      RSP: 002b:00007ffddbee2798 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fed9
      RDX: 0000000000000000 RSI: 0000000020005000 RDI: 0000000000000003
      RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401800
      R13: 0000000000401890 R14: 0000000000000000 R15: 0000000000000000
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
       kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
       kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
       kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
       slab_post_alloc_hook mm/slab.h:445 [inline]
       slab_alloc_node mm/slub.c:2737 [inline]
       __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
       __kmalloc_reserve net/core/skbuff.c:138 [inline]
       __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
       alloc_skb include/linux/skbuff.h:984 [inline]
       netlink_alloc_large_skb net/netlink/af_netlink.c:1183 [inline]
       netlink_sendmsg+0x9a6/0x1310 net/netlink/af_netlink.c:1875
       sock_sendmsg_nosec net/socket.c:630 [inline]
       sock_sendmsg net/socket.c:640 [inline]
       ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046
       __sys_sendmsg net/socket.c:2080 [inline]
       SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091
       SyS_sendmsg+0x54/0x80 net/socket.c:2087
       do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      
      Fixes: 21fdd092 ("net: Add support for filtering neigh dump by master device")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: David Ahern <dsa@cumulusnetworks.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7dd07c14