1. 21 Sep, 2017 13 commits
  2. 20 Sep, 2017 19 commits
  3. 19 Sep, 2017 8 commits
    • Matteo Croce's avatar
      ipv6: fix net.ipv6.conf.all interface DAD handlers · 35e015e1
      Matteo Croce authored
      Currently, writing into
      net.ipv6.conf.all.{accept_dad,use_optimistic,optimistic_dad} has no effect.
      Fix handling of these flags by:
      
      - using the maximum of global and per-interface values for the
        accept_dad flag. That is, if at least one of the two values is
        non-zero, enable DAD on the interface. If at least one value is
        set to 2, enable DAD and disable IPv6 operation on the interface if
        MAC-based link-local address was found
      
      - using the logical OR of global and per-interface values for the
        optimistic_dad flag. If at least one of them is set to one, optimistic
        duplicate address detection (RFC 4429) is enabled on the interface
      
      - using the logical OR of global and per-interface values for the
        use_optimistic flag. If at least one of them is set to one,
        optimistic addresses won't be marked as deprecated during source address
        selection on the interface.
      
      While at it, as we're modifying the prototype for ipv6_use_optimistic_addr(),
      drop inline, and let the compiler decide.
      
      Fixes: 7fd2561e ("net: ipv6: Add a sysctl to make optimistic addresses useful candidates")
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35e015e1
    • Mike Manning's avatar
      net: ipv6: fix regression of no RTM_DELADDR sent after DAD failure · 6819a14e
      Mike Manning authored
      Commit f784ad3d ("ipv6: do not send RTM_DELADDR for tentative
      addresses") incorrectly assumes that no RTM_NEWADDR are sent for
      addresses in tentative state, as this does happen for the standard
      IPv6 use-case of DAD failure, see the call to ipv6_ifa_notify() in
      addconf_dad_stop(). So as a result of this change, no RTM_DELADDR is
      sent after DAD failure for a link-local when strict DAD (accept_dad=2)
      is configured, or on the next admin down in other cases. The absence
      of this notification breaks backwards compatibility and causes problems
      after DAD failure if this notification was being relied on. The
      solution is to allow RTM_DELADDR to still be sent after DAD failure.
      
      Fixes: f784ad3d ("ipv6: do not send RTM_DELADDR for tentative addresses")
      Signed-off-by: default avatarMike Manning <mmanning@brocade.com>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6819a14e
    • Daniel Borkmann's avatar
      bpf: fix ri->map_owner pointer on bpf_prog_realloc · 7c300131
      Daniel Borkmann authored
      Commit 109980b8 ("bpf: don't select potentially stale
      ri->map from buggy xdp progs") passed the pointer to the prog
      itself to be loaded into r4 prior on bpf_redirect_map() helper
      call, so that we can store the owner into ri->map_owner out of
      the helper.
      
      Issue with that is that the actual address of the prog is still
      subject to change when subsequent rewrites occur that require
      slow path in bpf_prog_realloc() to alloc more memory, e.g. from
      patching inlining helper functions or constant blinding. Thus,
      we really need to take prog->aux as the address we're holding,
      which also works with prog clones as they share the same aux
      object.
      
      Instead of then fetching aux->prog during runtime, which could
      potentially incur cache misses due to false sharing, we are
      going to just use aux for comparison on the map owner. This
      will also keep the patchlet of the same size, and later check
      in xdp_map_invalid() only accesses read-only aux pointer from
      the prog, it's also in the same cacheline already from prior
      access when calling bpf_func.
      
      Fixes: 109980b8 ("bpf: don't select potentially stale ri->map from buggy xdp progs")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c300131
    • Christian Lamparter's avatar
      net: emac: Fix napi poll list corruption · f5595606
      Christian Lamparter authored
      This patch is pretty much a carbon copy of
      commit 3079c652 ("caif: Fix napi poll list corruption")
      with "caif" replaced by "emac".
      
      The commit d75b1ade ("net: less interrupt masking in NAPI")
      breaks emac.
      
      It is now required that if the entire budget is consumed when poll
      returns, the napi poll_list must remain empty.  However, like some
      other drivers emac tries to do a last-ditch check and if there is
      more work it will call napi_reschedule and then immediately process
      some of this new work.  Should the entire budget be consumed while
      processing such new work then we will violate the new caller
      contract.
      
      This patch fixes this by not touching any work when we reschedule
      in emac.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5595606
    • Eric Dumazet's avatar
      tcp: fastopen: fix on syn-data transmit failure · b5b7db8d
      Eric Dumazet authored
      Our recent change exposed a bug in TCP Fastopen Client that syzkaller
      found right away [1]
      
      When we prepare skb with SYN+DATA, we attempt to transmit it,
      and we update socket state as if the transmit was a success.
      
      In socket RTX queue we have two skbs, one with the SYN alone,
      and a second one containing the DATA.
      
      When (malicious) ACK comes in, we now complain that second one had no
      skb_mstamp.
      
      The proper fix is to make sure that if the transmit failed, we do not
      pretend we sent the DATA skb, and make it our send_head.
      
      When 3WHS completes, we can now send the DATA right away, without having
      to wait for a timeout.
      
      [1]
      WARNING: CPU: 0 PID: 100189 at net/ipv4/tcp_input.c:3117 tcp_clean_rtx_queue+0x2057/0x2ab0 net/ipv4/tcp_input.c:3117()
      
       WARN_ON_ONCE(last_ackt == 0);
      
      Modules linked in:
      CPU: 0 PID: 100189 Comm: syz-executor1 Not tainted
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
       0000000000000000 ffff8800b35cb1d8 ffffffff81cad00d 0000000000000000
       ffffffff828a4347 ffff88009f86c080 ffffffff8316eb20 0000000000000d7f
       ffff8800b35cb220 ffffffff812c33c2 ffff8800baad2440 00000009d46575c0
      Call Trace:
       [<ffffffff81cad00d>] __dump_stack
       [<ffffffff81cad00d>] dump_stack+0xc1/0x124
       [<ffffffff812c33c2>] warn_slowpath_common+0xe2/0x150
       [<ffffffff812c361e>] warn_slowpath_null+0x2e/0x40
       [<ffffffff828a4347>] tcp_clean_rtx_queue+0x2057/0x2ab0 n
       [<ffffffff828ae6fd>] tcp_ack+0x151d/0x3930
       [<ffffffff828baa09>] tcp_rcv_state_process+0x1c69/0x4fd0
       [<ffffffff828efb7f>] tcp_v4_do_rcv+0x54f/0x7c0
       [<ffffffff8258aacb>] sk_backlog_rcv
       [<ffffffff8258aacb>] __release_sock+0x12b/0x3a0
       [<ffffffff8258ad9e>] release_sock+0x5e/0x1c0
       [<ffffffff8294a785>] inet_wait_for_connect
       [<ffffffff8294a785>] __inet_stream_connect+0x545/0xc50
       [<ffffffff82886f08>] tcp_sendmsg_fastopen
       [<ffffffff82886f08>] tcp_sendmsg+0x2298/0x35a0
       [<ffffffff82952515>] inet_sendmsg+0xe5/0x520
       [<ffffffff8257152f>] sock_sendmsg_nosec
       [<ffffffff8257152f>] sock_sendmsg+0xcf/0x110
      
      Fixes: 8c72c65b ("tcp: update skb->skb_mstamp more carefully")
      Fixes: 783237e8 ("net-tcp: Fast Open client - sending SYN-data")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5b7db8d
    • David S. Miller's avatar
      Merge branch 'hns3-bug-fixes' · 1e513b6b
      David S. Miller authored
      Salil Mehta says:
      
      ====================
      Bug fixes for the HNS3 Ethernet Driver for Hip08 SoC
      
      This patch set presents some bug fixes for the HNS3 Ethernet driver identified
      during internal testing & stabilization efforts.
      
      Change Log:
      Patch V2: Resolved comments from Leon Romanovsky
      Patch V1: Initial Submit
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e513b6b
    • Lipeng's avatar
      net: hns3: Fixes the premature exit of loop when matching clients · 90f7b11a
      Lipeng authored
      When register/unregister ae_dev, ae_dev should match all client
      in the client_list. Enet and roce can co-exists together so we
      should continue checking for enet and roce presence together.
      So break should not be there.
      
      Above caused problems in loading and unloading of modules.
      
      Fixes: 38eddd126772 ("net: hns3: Add support of the HNAE3 framework")
      Signed-off-by: default avatarLipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90f7b11a
    • Lipeng's avatar
      net: hns3: Fixes the default VLAN-id of PF · 5e43aef8
      Lipeng authored
      When there is no vlan id in the packets, hardware will treat the vlan id
      as 0 and look for the mac_vlan table. This patch set the default vlan id
      of PF as 0. Without this config, it will fail when look for mac_vlan
      table, and hardware will drop packets.
      
      Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine &
      Compatibility Layer Support")
      Signed-off-by: default avatarMingguang Qu <qumingguang@huawei.com>
      Signed-off-by: default avatarLipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e43aef8