1. 21 Sep, 2017 1 commit
  2. 20 Sep, 2017 19 commits
  3. 19 Sep, 2017 20 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
    • Salil Mehta's avatar
      net: hns3: Fixes the ether address copy with appropriate API · fbbb1536
      Salil Mehta authored
      This patch replaces the ethernet address copy instance with more
      appropriate ether_addr_copy() function.
      
      Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine &
      Compatibility Layer Support")
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbbb1536
    • Lipeng's avatar
      net: hns3: Fixes the initialization of MAC address in hardware · 139e8792
      Lipeng authored
      This patch fixes the initialization of MAC address, fetched from HNS3
      firmware i.e. when it is not randomly generated, to the HNS3 hardware.
      
      Fixes: ca60906d2795 ("net: hns3: Add support of HNS3 Ethernet Driver for
      hip08 SoC")
      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>
      139e8792
    • Lipeng's avatar
      net: hns3: Fixes ring-to-vector map-and-unmap command · 0305b443
      Lipeng authored
      This patch fixes the vector-to-ring map and unmap command and adds
      INT_GL(for, Gap Limiting Interrupts) and VF id to it as required
      by the hardware interface.
      
      Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine &
      Compatibility Layer Support")
      Signed-off-by: default avatarLipeng <lipeng321@huawei.com>
      Signed-off-by: default avatarMingguang Qu <qumingguang@huawei.com>
      Signed-off-by: default avatarSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0305b443
    • Lipeng's avatar
      net: hns3: Fixes the command used to unmap ring from vector · c5b1b975
      Lipeng authored
      This patch fixes the IMP command being used to unmap the vector
      from the corresponding ring.
      
      Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine &
      Compatibility Layer Support")
      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>
      c5b1b975
    • Lipeng's avatar
      net: hns3: Fixes initialization of phy address from firmware · 2a4776e1
      Lipeng authored
      Default phy address of every port is 0. Therefore, phy address for
      each port need to be fetched from firmware and device initialized
      with fetched non-default phy address.
      
      Fixes: 6427264ef330 ("net: hns3: Add HNS3 Acceleration Engine &
      Compatibility Layer Support")
      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>
      2a4776e1
    • Eric Dumazet's avatar
      bpf: do not disable/enable BH in bpf_map_free_id() · 930651a7
      Eric Dumazet authored
      syzkaller reported following splat [1]
      
      Since hard irq are disabled by the caller, bpf_map_free_id()
      should not try to enable/disable BH.
      
      Another solution would be to change htab_map_delete_elem() to
      defer the free_htab_elem() call after
      raw_spin_unlock_irqrestore(&b->lock, flags), but this might be not
      enough to cover other code paths.
      
      [1]
      WARNING: CPU: 1 PID: 8052 at kernel/softirq.c:161 __local_bh_enable_ip
      +0x1e/0x160 kernel/softirq.c:161
      Kernel panic - not syncing: panic_on_warn set ...
      
      CPU: 1 PID: 8052 Comm: syz-executor1 Not tainted 4.13.0-next-20170915+
      #23
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:16 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:52
       panic+0x1e4/0x417 kernel/panic.c:181
       __warn+0x1c4/0x1d9 kernel/panic.c:542
       report_bug+0x211/0x2d0 lib/bug.c:183
       fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:178
       do_trap_no_signal arch/x86/kernel/traps.c:212 [inline]
       do_trap+0x260/0x390 arch/x86/kernel/traps.c:261
       do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:298
       do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:311
       invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905
      RIP: 0010:__local_bh_enable_ip+0x1e/0x160 kernel/softirq.c:161
      RSP: 0018:ffff8801cdcd7748 EFLAGS: 00010046
      RAX: 0000000000000082 RBX: 0000000000000201 RCX: 0000000000000000
      RDX: 1ffffffff0b5933c RSI: 0000000000000201 RDI: ffffffff85ac99e0
      RBP: ffff8801cdcd7758 R08: ffffffff85b87158 R09: 1ffff10039b9aec6
      R10: ffff8801c99f24c0 R11: 0000000000000002 R12: ffffffff817b0b47
      R13: dffffc0000000000 R14: ffff8801cdcd77e8 R15: 0000000000000001
       __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:176 [inline]
       _raw_spin_unlock_bh+0x30/0x40 kernel/locking/spinlock.c:207
       spin_unlock_bh include/linux/spinlock.h:361 [inline]
       bpf_map_free_id kernel/bpf/syscall.c:197 [inline]
       __bpf_map_put+0x267/0x320 kernel/bpf/syscall.c:227
       bpf_map_put+0x1a/0x20 kernel/bpf/syscall.c:235
       bpf_map_fd_put_ptr+0x15/0x20 kernel/bpf/map_in_map.c:96
       free_htab_elem+0xc3/0x1b0 kernel/bpf/hashtab.c:658
       htab_map_delete_elem+0x74d/0x970 kernel/bpf/hashtab.c:1063
       map_delete_elem kernel/bpf/syscall.c:633 [inline]
       SYSC_bpf kernel/bpf/syscall.c:1479 [inline]
       SyS_bpf+0x2188/0x46a0 kernel/bpf/syscall.c:1451
       entry_SYSCALL_64_fastpath+0x1f/0xbe
      
      Fixes: f3f1c054 ("bpf: Introduce bpf_map ID")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      930651a7
    • Andreas Gruenbacher's avatar
      rhashtable: Documentation tweak · 0647169c
      Andreas Gruenbacher authored
      Clarify that rhashtable_walk_{stop,start} will not reset the iterator to
      the beginning of the hash table.  Confusion between rhashtable_walk_enter
      and rhashtable_walk_start has already lead to a bug.
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0647169c
    • Jerome Brunet's avatar
      net: phy: Kconfig: Fix PHY infrastructure menu in menuconfig · 6073512c
      Jerome Brunet authored
      Since the integration of PHYLINK, the configuration option which
      used to be under the PHY infrastructure menu in menuconfig ended
      up one level up (the network device driver section)
      
      By placing PHYLINK option right after PHYLIB entry, it broke the
      way Kconfig used to build the menu. See kconfig-language.txt, section
      "Menu structure", 2nd method.
      
      This is fixed by placing the PHYLINK option just before PHYLIB.
      
      Fixes: 9525ae83 ("phylink: add phylink infrastructure")
      Signed-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6073512c
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2017-11-19' of... · fd0e4c59
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2017-11-19' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      Just two netlink fixes, both allowing privileged users
      to crash the kernel with malformed netlink messages.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd0e4c59
    • Ariel Elior's avatar
      MAINTAINERS: Remove Yuval Mintz from maintainers list · 3993491b
      Ariel Elior authored
      Remove Yuval from maintaining the bnx2x & qed* modules as he is no longer
      working for the company. Thanks Yuval for your huge contributions and
      tireless efforts over the many years and various companies.
      
      Ariel
      Signed-off-by: default avatarAriel Elior <aelior@cavium.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3993491b
    • Florian Fainelli's avatar
      net: systemport: Fix 64-bit statistics dependency · 8ecb1a29
      Florian Fainelli authored
      There are several problems with commit 10377ba7 ("net: systemport:
      Support 64bit statistics", first one got fixed in 7095c973 ("net:
      systemport: Fix 64-bit stats deadlock").
      
      The second problem is that this specific code updates the
      stats64.tx_{packets,bytes} from ndo_get_stats64() and that is what we
      are returning to ethtool -S. If we are not running a tool that involves
      calling ndo_get_stats64(), then we won't get updated ethtool stats.
      
      The solution to this is to update the stats from both call sites,
      factoring that into a specific function, While at it, don't just check
      the sizeof() but also the type of the statistics in order to use the
      64-bit stats seqlock.
      
      Fixes: 10377ba7 ("net: systemport: Support 64bit statistics")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ecb1a29
    • Eric Dumazet's avatar
      8139too: revisit napi_complete_done() usage · 129c6cda
      Eric Dumazet authored
      It seems we have to be more careful in napi_complete_done()
      use. This patch is not a revert, as it seems we can
      avoid bug that Ville reported by moving the napi_complete_done()
      test in the spinlock section.
      
      Many thanks to Ville for detective work and all tests.
      
      Fixes: 617f0121 ("8139too: use napi_complete_done()")
      Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      129c6cda