1. 17 Feb, 2020 12 commits
    • Nikita Danilov's avatar
      net: atlantic: better loopback mode handling · b42726fc
      Nikita Danilov authored
      Add checks to not enable multiple loopback modes simultaneously,
      It was also discovered that for dma loopback to function correctly
      promisc mode should be enabled on device.
      
      Fixes: ea4b4d7f ("net: atlantic: loopback tests via private flags")
      Signed-off-by: default avatarNikita Danilov <ndanilov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b42726fc
    • Egor Pomozov's avatar
      net: atlantic: ptp gpio adjustments · f08a464c
      Egor Pomozov authored
      Clock adjustment data should be passed to FW as well, otherwise in some
      cases a drift was observed when using GPIO features.
      Signed-off-by: default avatarEgor Pomozov <epomozov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f08a464c
    • Igor Russkikh's avatar
      net: atlantic: check rpc result and wait for rpc address · e7b5f97e
      Igor Russkikh authored
      Artificial HW reliability tests revealed a possible hangup in
      the driver. Normally, when device disappears from bus, all
      register reads returns 0xFFFFFFFF.
      
      At remote procedure invocation towards FW there is a logic
      where result is compared with -1 in a loop.
      That caused an infinite loop if hardware due to some issues
      disappears from bus.
      
      Add extra result checks to prevent this.
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7b5f97e
    • Dmitry Bezrukov's avatar
      net: atlantic: checksum compat issue · 15beab0a
      Dmitry Bezrukov authored
      Yet another checksum offload compatibility issue was found.
      
      The known issue is that AQC HW marks tcp packets with 0xFFFF checksum
      as invalid (1). This is workarounded in driver, passing all the suspicious
      packets up to the stack for further csum validation.
      
      Another HW problem (2) is that it hides invalid csum of LRO aggregated
      packets inside of the individual descriptors. That was workarounded
      by forced scan of all LRO descriptors for checksum errors.
      
      However the scan logic was joint for both LRO and multi-descriptor
      packets (jumbos). And this causes the issue.
      
      We have to drop LRO packets with the detected bad checksum
      because of (2), but we have to pass jumbo packets to stack because of (1).
      
      When using windows tcp partner with jumbo frames but with LSO disabled
      driver discards such frames as bad checksummed. But only LRO frames
      should be dropped, not jumbos.
      
      On such a configurations tcp stream have a chance of drops and stucks.
      
      (1) 76f254d4 ("net: aquantia: tcp checksum 0xffff being handled incorrectly")
      (2) d08b9a0a ("net: aquantia: do not pass lro session with invalid tcp checksum")
      
      Fixes: d08b9a0a ("net: aquantia: do not pass lro session with invalid tcp checksum")
      Signed-off-by: default avatarDmitry Bezrukov <dbezrukov@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15beab0a
    • Hangbin Liu's avatar
      selftests: forwarding: vxlan_bridge_1d: fix tos value · 4e867c9a
      Hangbin Liu authored
      After commit 71130f29 ("vxlan: fix tos value before xmit") we start
      strict vxlan xmit tos value by RT_TOS(), which limits the tos value less
      than 0x1E. With current value 0x40 the test will failed with "v1: Expected
      to capture 10 packets, got 0". So let's choose a smaller tos value for
      testing.
      
      Fixes: d417ecf5 ("selftests: forwarding: vxlan_bridge_1d: Add a TOS test")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e867c9a
    • Eric Dumazet's avatar
      net: rtnetlink: fix bugs in rtnl_alt_ifname() · 44bfa9c5
      Eric Dumazet authored
      Since IFLA_ALT_IFNAME is an NLA_STRING, we have no
      guarantee it is nul terminated.
      
      We should use nla_strdup() instead of kstrdup(), since this
      helper will make sure not accessing out-of-bounds data.
      
      BUG: KMSAN: uninit-value in strlen+0x5e/0xa0 lib/string.c:535
      CPU: 1 PID: 19157 Comm: syz-executor.5 Not tainted 5.5.0-rc5-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x1c9/0x220 lib/dump_stack.c:118
       kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
       __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
       strlen+0x5e/0xa0 lib/string.c:535
       kstrdup+0x7f/0x1a0 mm/util.c:59
       rtnl_alt_ifname net/core/rtnetlink.c:3495 [inline]
       rtnl_linkprop+0x85d/0xc00 net/core/rtnetlink.c:3553
       rtnl_newlinkprop+0x9d/0xb0 net/core/rtnetlink.c:3568
       rtnetlink_rcv_msg+0x1153/0x1570 net/core/rtnetlink.c:5424
       netlink_rcv_skb+0x451/0x650 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5442
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0xf9e/0x1100 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x1248/0x14d0 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:639 [inline]
       sock_sendmsg net/socket.c:659 [inline]
       ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
       ___sys_sendmsg net/socket.c:2384 [inline]
       __sys_sendmsg+0x451/0x5f0 net/socket.c:2417
       __do_sys_sendmsg net/socket.c:2426 [inline]
       __se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
       do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x45b3b9
      Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007ff1c7b1ac78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007ff1c7b1b6d4 RCX: 000000000045b3b9
      RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000003
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
      R13: 00000000000009cb R14: 00000000004cb3dd R15: 000000000075bf2c
      
      Uninit was created at:
       kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline]
       kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127
       kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:82
       slab_alloc_node mm/slub.c:2774 [inline]
       __kmalloc_node_track_caller+0xb40/0x1200 mm/slub.c:4382
       __kmalloc_reserve net/core/skbuff.c:141 [inline]
       __alloc_skb+0x2fd/0xac0 net/core/skbuff.c:209
       alloc_skb include/linux/skbuff.h:1049 [inline]
       netlink_alloc_large_skb net/netlink/af_netlink.c:1174 [inline]
       netlink_sendmsg+0x7d3/0x14d0 net/netlink/af_netlink.c:1892
       sock_sendmsg_nosec net/socket.c:639 [inline]
       sock_sendmsg net/socket.c:659 [inline]
       ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2330
       ___sys_sendmsg net/socket.c:2384 [inline]
       __sys_sendmsg+0x451/0x5f0 net/socket.c:2417
       __do_sys_sendmsg net/socket.c:2426 [inline]
       __se_sys_sendmsg+0x97/0xb0 net/socket.c:2424
       __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2424
       do_syscall_64+0xb8/0x160 arch/x86/entry/common.c:296
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 36fbf1e5 ("net: rtnetlink: add linkprop commands to add and delete alternative ifnames")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      44bfa9c5
    • Alexandre Belloni's avatar
      net: macb: ensure interface is not suspended on at91rm9200 · e6a41c23
      Alexandre Belloni authored
      Because of autosuspend, at91ether_start is called with clocks disabled.
      Ensure that pm_runtime doesn't suspend the interface as soon as it is
      opened as there is no pm_runtime support is the other relevant parts of the
      platform support for at91rm9200.
      
      Fixes: d54f89af ("net: macb: Add pm runtime support")
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Reviewed-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6a41c23
    • Jethro Beekman's avatar
      net: fib_rules: Correctly set table field when table number exceeds 8 bits · 540e585a
      Jethro Beekman authored
      In 709772e6, RT_TABLE_COMPAT was added to
      allow legacy software to deal with routing table numbers >= 256, but the
      same change to FIB rule queries was overlooked.
      Signed-off-by: default avatarJethro Beekman <jethro@fortanix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      540e585a
    • Leon Romanovsky's avatar
      net/rds: Track user mapped pages through special API · 0d4597c8
      Leon Romanovsky authored
      Convert net/rds to use the newly introduces pin_user_pages() API,
      which properly sets FOLL_PIN. Setting FOLL_PIN is now required for
      code that requires tracking of pinned pages.
      
      Note that this effectively changes the code's behavior: it now
      ultimately calls set_page_dirty_lock(), instead of set_page_dirty().
      This is probably more accurate.
      
      As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
      dealing with a file backed page where we have reference on the inode it
      hangs off." [1]
      
      [1] https://lore.kernel.org/r/20190723153640.GB720@lst.de
      
      Cc: Hans Westgaard Ry <hans.westgaard.ry@oracle.com>
      Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJohn Hubbard <jhubbard@nvidia.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d4597c8
    • Benjamin Poirier's avatar
      ipv6: Fix nlmsg_flags when splitting a multipath route · afecdb37
      Benjamin Poirier authored
      When splitting an RTA_MULTIPATH request into multiple routes and adding the
      second and later components, we must not simply remove NLM_F_REPLACE but
      instead replace it by NLM_F_CREATE. Otherwise, it may look like the netlink
      message was malformed.
      
      For example,
      	ip route add 2001:db8::1/128 dev dummy0
      	ip route change 2001:db8::1/128 nexthop via fe80::30:1 dev dummy0 \
      		nexthop via fe80::30:2 dev dummy0
      results in the following warnings:
      [ 1035.057019] IPv6: RTM_NEWROUTE with no NLM_F_CREATE or NLM_F_REPLACE
      [ 1035.057517] IPv6: NLM_F_CREATE should be set when creating new route
      
      This patch makes the nlmsg sequence look equivalent for __ip6_ins_rt() to
      what it would get if the multipath route had been added in multiple netlink
      operations:
      	ip route add 2001:db8::1/128 dev dummy0
      	ip route change 2001:db8::1/128 nexthop via fe80::30:1 dev dummy0
      	ip route append 2001:db8::1/128 nexthop via fe80::30:2 dev dummy0
      
      Fixes: 27596472 ("ipv6: fix ECMP route replacement")
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@cumulusnetworks.com>
      Reviewed-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      afecdb37
    • Benjamin Poirier's avatar
      ipv6: Fix route replacement with dev-only route · e404b8c7
      Benjamin Poirier authored
      After commit 27596472 ("ipv6: fix ECMP route replacement") it is no
      longer possible to replace an ECMP-able route by a non ECMP-able route.
      For example,
      	ip route add 2001:db8::1/128 via fe80::1 dev dummy0
      	ip route replace 2001:db8::1/128 dev dummy0
      does not work as expected.
      
      Tweak the replacement logic so that point 3 in the log of the above commit
      becomes:
      3. If the new route is not ECMP-able, and no matching non-ECMP-able route
      exists, replace matching ECMP-able route (if any) or add the new route.
      
      We can now summarize the entire replace semantics to:
      When doing a replace, prefer replacing a matching route of the same
      "ECMP-able-ness" as the replace argument. If there is no such candidate,
      fallback to the first route found.
      
      Fixes: 27596472 ("ipv6: fix ECMP route replacement")
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@cumulusnetworks.com>
      Reviewed-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e404b8c7
    • Hangbin Liu's avatar
      selftests: forwarding: use proto icmp for {gretap, ip6gretap}_mac testing · e8023b03
      Hangbin Liu authored
      For tc ip_proto filter, when we extract the flow via __skb_flow_dissect()
      without flag FLOW_DISSECTOR_F_STOP_AT_ENCAP, we will continue extract to
      the inner proto.
      
      So for GRE + ICMP messages, we should not track GRE proto, but inner ICMP
      proto.
      
      For test mirror_gre.sh, it may make user confused if we capture ICMP
      message on $h3(since the flow is GRE message). So I move the capture
      dev to h3-gt{4,6}, and only capture ICMP message.
      
      Before the fix:
      ]# ./mirror_gre.sh
      TEST: ingress mirror to gretap (skip_hw)                            [ OK ]
      TEST: egress mirror to gretap (skip_hw)                             [ OK ]
      TEST: ingress mirror to ip6gretap (skip_hw)                         [ OK ]
      TEST: egress mirror to ip6gretap (skip_hw)                          [ OK ]
      TEST: ingress mirror to gretap: envelope MAC (skip_hw)              [FAIL]
       Expected to capture 10 packets, got 0.
      TEST: egress mirror to gretap: envelope MAC (skip_hw)               [FAIL]
       Expected to capture 10 packets, got 0.
      TEST: ingress mirror to ip6gretap: envelope MAC (skip_hw)           [FAIL]
       Expected to capture 10 packets, got 0.
      TEST: egress mirror to ip6gretap: envelope MAC (skip_hw)            [FAIL]
       Expected to capture 10 packets, got 0.
      TEST: two simultaneously configured mirrors (skip_hw)               [ OK ]
      WARN: Could not test offloaded functionality
      
      After fix:
      ]# ./mirror_gre.sh
      TEST: ingress mirror to gretap (skip_hw)                            [ OK ]
      TEST: egress mirror to gretap (skip_hw)                             [ OK ]
      TEST: ingress mirror to ip6gretap (skip_hw)                         [ OK ]
      TEST: egress mirror to ip6gretap (skip_hw)                          [ OK ]
      TEST: ingress mirror to gretap: envelope MAC (skip_hw)              [ OK ]
      TEST: egress mirror to gretap: envelope MAC (skip_hw)               [ OK ]
      TEST: ingress mirror to ip6gretap: envelope MAC (skip_hw)           [ OK ]
      TEST: egress mirror to ip6gretap: envelope MAC (skip_hw)            [ OK ]
      TEST: two simultaneously configured mirrors (skip_hw)               [ OK ]
      WARN: Could not test offloaded functionality
      
      Fixes: ba8d3987 ("selftests: forwarding: Add test for mirror to gretap")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Reviewed-by: default avatarPetr Machata <pmachata@gmail.com>
      Tested-by: default avatarPetr Machata <pmachata@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8023b03
  2. 14 Feb, 2020 24 commits
  3. 13 Feb, 2020 4 commits
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · b19e8c68
      Linus Torvalds authored
      Pull arm64 fixes from Will Deacon:
       "Summary below, but it's all reasonably straightforward. There are some
        more fixes on the horizon, but nothing disastrous yet.
      
        Summary:
      
         - Fix build when KASLR is enabled but CONFIG_ARCH_RANDOM is not set
      
         - Fix context-switching of SSBS state on systems that implement it
      
         - Fix spinlock compiler warning introduced during the merge window
      
         - Fix incorrect header inclusion (linux/clk-provider.h)
      
         - Use SYSCTL_{ZERO,ONE} instead of rolling our own static variables
      
         - Don't scream if optional SMMUv3 PMU irq is missing
      
         - Remove some unused function prototypes"
      
      * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
        arm64: time: Replace <linux/clk-provider.h> by <linux/of_clk.h>
        arm64: Fix CONFIG_ARCH_RANDOM=n build
        perf/smmuv3: Use platform_get_irq_optional() for wired interrupt
        arm64/spinlock: fix a -Wunused-function warning
        arm64: ssbs: Fix context-switch when SSBS is present on all CPUs
        arm64: use shared sysctl constants
        arm64: Drop do_el0_ia_bp_hardening() & do_sp_pc_abort() declarations
      b19e8c68
    • Linus Torvalds's avatar
      Merge tag 'gpio-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · 1d40890a
      Linus Torvalds authored
      Pull GPIO fixes from Linus Walleij:
      
       - Revert two patches to gpio_do_set_config() and implement the proper
         solution that works, also drop an unecessary call in set_config()
      
       - Fix up the lockdep class for hierarchical IRQ domains.
      
       - Remove some bridge code for line directions.
      
       - Fix a register access bug in the Xilinx driver.
      
      * tag 'gpio-v5.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        gpio: sifive: fix static checker warning
        spmi: pmic-arb: Set lockdep class for hierarchical irq domains
        gpio: xilinx: Fix bug where the wrong GPIO register is written to
        gpiolib: remove unnecessary argument from set_config call
        gpio: bd71828: Remove unneeded defines for GPIO_LINE_DIRECTION_IN/OUT
        MAINTAINERS: Sort entries in database for GPIO
        gpiolib: fix gpio_do_set_config()
        Revert "gpiolib: remove set but not used variable 'config'"
        Revert "gpiolib: Remove duplicated function gpio_do_set_config()"
      1d40890a
    • David S. Miller's avatar
      Merge branch 'icmp-account-for-NAT-when-sending-icmps-from-ndo-layer' · 803381f9
      David S. Miller authored
      Jason A. Donenfeld says:
      
      ====================
      icmp: account for NAT when sending icmps from ndo layer
      
      The ICMP routines use the source address for two reasons:
      
      1. Rate-limiting ICMP transmissions based on source address, so
         that one source address cannot provoke a flood of replies. If
         the source address is wrong, the rate limiting will be
         incorrectly applied.
      
      2. Choosing the interface and hence new source address of the
         generated ICMP packet. If the original packet source address
         is wrong, ICMP replies will be sent from the wrong source
         address, resulting in either a misdelivery, infoleak, or just
         general network admin confusion.
      
      Most of the time, the icmp_send and icmpv6_send routines can just reach
      down into the skb's IP header to determine the saddr. However, if
      icmp_send or icmpv6_send is being called from a network device driver --
      there are a few in the tree -- then it's possible that by the time
      icmp_send or icmpv6_send looks at the packet, the packet's source
      address has already been transformed by SNAT or MASQUERADE or some other
      transformation that CONNTRACK knows about. In this case, the packet's
      source address is most certainly the *wrong* source address to be used
      for the purpose of ICMP replies.
      
      Rather, the source address we want to use for ICMP replies is the
      original one, from before the transformation occurred.
      
      Fortunately, it's very easy to just ask CONNTRACK if it knows about this
      packet, and if so, how to fix it up. The saddr is the only field in the
      header we need to fix up, for the purposes of the subsequent processing
      in the icmp_send and icmpv6_send functions, so we do the lookup very
      early on, so that the rest of the ICMP machinery can progress as usual.
      
      Changes v3->v4:
      - Add back the skb_shared checking, since the previous assumption isn't
        actually true [Eric]. This implies dropping the additional patches v3 had
        for removing skb_share_check from various drivers. We can revisit that
        general set of ideas later, but that's probably better suited as a net-next
        patchset rather than this stable one which is geared at fixing bugs. So,
        this implements things in the safe conservative way.
      
      Changes v2->v3:
      - Add selftest to ensure this actually does what we want and never regresses.
      - Check the size of the skb header before operating on it.
      - Use skb_ensure_writable to ensure we can modify the cloned skb [Florian].
      - Conditionalize this on IPS_SRC_NAT so we don't do anything unnecessarily
        [Florian].
      - It turns out that since we're calling these from the xmit path,
        skb_share_check isn't required, so remove that [Florian]. This simplifes the
        code a bit too. **The supposition here is that skbs passed to ndo_start_xmit
        are _never_ shared. If this is not correct NOW IS THE TIME TO PIPE UP, for
        doom awaits us later.**
      - While investigating the shared skb business, several drivers appeared to be
        calling it incorrectly in the xmit path, so this series also removes those
        unnecessary calls, based on the supposition mentioned in the previous point.
      
      Changes v1->v2:
      - icmpv6 takes subtly different types than icmpv4, like u32 instead of be32,
        u8 instead of int.
      - Since we're technically writing to the skb, we need to make sure it's not
        a shared one [Dave, 2017].
      - Restore the original skb data after icmp_send returns. All current users
        are freeing the packet right after, so it doesn't matter, but future users
        might not.
      - Remove superfluous route lookup in sunvnet [Dave].
      - Use NF_NAT instead of NF_CONNTRACK for condition [Florian].
      - Include this cover letter [Dave].
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      803381f9
    • Jason A. Donenfeld's avatar
      xfrm: interface: use icmp_ndo_send helper · 45942ba8
      Jason A. Donenfeld authored
      Because xfrmi is calling icmp from network device context, it should use
      the ndo helper so that the rate limiting applies correctly.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45942ba8