1. 30 4月, 2018 1 次提交
    • W
      erspan: auto detect truncated packets. · 1baf5ebf
      William Tu 提交于
      Currently the truncated bit is set only when the mirrored packet
      is larger than mtu.  For certain cases, the packet might already
      been truncated before sending to the erspan tunnel.  In this case,
      the patch detect whether the IP header's total length is larger
      than the actual skb->len.  If true, this indicated that the
      mirrored packet is truncated and set the erspan truncate bit.
      
      I tested the patch using bpf_skb_change_tail helper function to
      shrink the packet size and send to erspan tunnel.
      Reported-by: NXiaoyan Jin <xiaoyanj@vmware.com>
      Signed-off-by: NWilliam Tu <u9012063@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1baf5ebf
  2. 06 4月, 2018 1 次提交
    • E
      ip6_gre: better validate user provided tunnel names · 5f42df01
      Eric Dumazet 提交于
      Use dev_valid_name() to make sure user does not provide illegal
      device name.
      
      syzbot caught the following bug :
      
      BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
      BUG: KASAN: stack-out-of-bounds in ip6gre_tunnel_locate+0x334/0x860 net/ipv6/ip6_gre.c:339
      Write of size 20 at addr ffff8801afb9f7b8 by task syzkaller851048/4466
      
      CPU: 1 PID: 4466 Comm: syzkaller851048 Not tainted 4.16.0+ #1
      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+0x1b9/0x29f lib/dump_stack.c:53
       print_address_description+0x6c/0x20b mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:354 [inline]
       kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
       check_memory_region_inline mm/kasan/kasan.c:260 [inline]
       check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
       memcpy+0x37/0x50 mm/kasan/kasan.c:303
       strlcpy include/linux/string.h:300 [inline]
       ip6gre_tunnel_locate+0x334/0x860 net/ipv6/ip6_gre.c:339
       ip6gre_tunnel_ioctl+0x69d/0x12e0 net/ipv6/ip6_gre.c:1195
       dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
       dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
       sock_ioctl+0x47e/0x680 net/socket.c:1015
       vfs_ioctl fs/ioctl.c:46 [inline]
       file_ioctl fs/ioctl.c:500 [inline]
       do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
       ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
       SYSC_ioctl fs/ioctl.c:708 [inline]
       SyS_ioctl+0x24/0x30 fs/ioctl.c:706
       do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
       entry_SYSCALL_64_after_hwframe+0x42/0xb7
      
      Fixes: c12b395a ("gre: Support GRE over IPv6")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f42df01
  3. 02 4月, 2018 1 次提交
  4. 28 3月, 2018 1 次提交
  5. 23 3月, 2018 1 次提交
  6. 10 3月, 2018 4 次提交
  7. 05 3月, 2018 2 次提交
  8. 28 2月, 2018 2 次提交
  9. 07 2月, 2018 2 次提交
  10. 26 1月, 2018 1 次提交
  11. 19 1月, 2018 1 次提交
    • A
      ip6_gre: init dev->mtu and dev->hard_header_len correctly · 128bb975
      Alexey Kodanev 提交于
      Commit b05229f4 ("gre6: Cleanup GREv6 transmit path,
      call common GRE functions") moved dev->mtu initialization
      from ip6gre_tunnel_setup() to ip6gre_tunnel_init(), as a
      result, the previously set values, before ndo_init(), are
      reset in the following cases:
      
      * rtnl_create_link() can update dev->mtu from IFLA_MTU
        parameter.
      
      * ip6gre_tnl_link_config() is invoked before ndo_init() in
        netlink and ioctl setup, so ndo_init() can reset MTU
        adjustments with the lower device MTU as well, dev->mtu
        and dev->hard_header_len.
      
        Not applicable for ip6gretap because it has one more call
        to ip6gre_tnl_link_config(tunnel, 1) in ip6gre_tap_init().
      
      Fix the first case by updating dev->mtu with 'tb[IFLA_MTU]'
      parameter if a user sets it manually on a device creation,
      and fix the second one by moving ip6gre_tnl_link_config()
      call after register_netdevice().
      
      Fixes: b05229f4 ("gre6: Cleanup GREv6 transmit path, call common GRE functions")
      Fixes: db2ec95d ("ip6_gre: Fix MTU setting")
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      128bb975
  12. 27 12月, 2017 2 次提交
    • W
      net: erspan: remove md NULL check · 214bb1c7
      William Tu 提交于
      The 'md' is allocated from 'tun_dst = ip_tun_rx_dst' and
      since we've checked 'tun_dst', 'md' will never be NULL.
      The patch removes it at both ipv4 and ipv6 erspan.
      
      Fixes: afb4c97d ("ip6_gre: fix potential memory leak in ip6erspan_rcv")
      Fixes: 50670b6e ("ip_gre: fix potential memory leak in erspan_rcv")
      Cc: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: NWilliam Tu <u9012063@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      214bb1c7
    • A
      ip6_gre: fix device features for ioctl setup · e5a9336a
      Alexey Kodanev 提交于
      When ip6gre is created using ioctl, its features, such as
      scatter-gather, GSO and tx-checksumming will be turned off:
      
        # ip -f inet6 tunnel add gre6 mode ip6gre remote fd00::1
        # ethtool -k gre6 (truncated output)
          tx-checksumming: off
          scatter-gather: off
          tcp-segmentation-offload: off
          generic-segmentation-offload: off [requested on]
      
      But when netlink is used, they will be enabled:
        # ip link add gre6 type ip6gre remote fd00::1
        # ethtool -k gre6 (truncated output)
          tx-checksumming: on
          scatter-gather: on
          tcp-segmentation-offload: on
          generic-segmentation-offload: on
      
      This results in a loss of performance when gre6 is created via ioctl.
      The issue was found with LTP/gre tests.
      
      Fix it by moving the setup of device features to a separate function
      and invoke it with ndo_init callback because both netlink and ioctl
      will eventually call it via register_netdevice():
      
         register_netdevice()
             - ndo_init() callback -> ip6gre_tunnel_init() or ip6gre_tap_init()
                 - ip6gre_tunnel_init_common()
                      - ip6gre_tnl_init_features()
      
      The moved code also contains two minor style fixes:
        * removed needless tab from GRE6_FEATURES on NETIF_F_HIGHDMA line.
        * fixed the issue reported by checkpatch: "Unnecessary parentheses around
          'nt->encap.type == TUNNEL_ENCAP_NONE'"
      
      Fixes: ac4eb009 ("ip6gre: Add support for basic offloads offloads excluding GSO")
      Signed-off-by: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5a9336a
  13. 21 12月, 2017 3 次提交
  14. 20 12月, 2017 1 次提交
  15. 19 12月, 2017 2 次提交
  16. 16 12月, 2017 2 次提交
  17. 07 12月, 2017 1 次提交
  18. 05 12月, 2017 1 次提交
  19. 02 12月, 2017 2 次提交
  20. 19 11月, 2017 1 次提交
  21. 13 11月, 2017 2 次提交
    • X
      ip6_gre: process toobig in a better way · fe1a4ca0
      Xin Long 提交于
      Now ip6gre processes toobig icmp packet by setting gre dev's mtu in
      ip6gre_err, which would cause few things not good:
      
        - It couldn't set mtu with dev_set_mtu due to it's not in user context,
          which causes route cache and idev->cnf.mtu6 not to be updated.
      
        - It has to update sk dst pmtu in tx path according to gredev->mtu for
          ip6gre, while it updates pmtu again according to lower dst pmtu in
          ip6_tnl_xmit.
      
        - To change dev->mtu by toobig icmp packet is not a good idea, it should
          only work on pmtu.
      
      This patch is to process toobig by updating the lower dst's pmtu, as later
      sk dst pmtu will be updated in ip6_tnl_xmit, the same way as in ip4gre.
      
      Note that gre dev's mtu will not be updated any more, it doesn't make any
      sense to change dev's mtu after receiving a toobig packet.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe1a4ca0
    • X
      ip6_gre: add the process for redirect in ip6gre_err · 929fc032
      Xin Long 提交于
      This patch is to add redirect icmp packet process for ip6gre by
      calling ip6_redirect() in ip6gre_err(), as in vti6_err.
      
      Prior to this patch, there's even no route cache generated after
      receiving redirect.
      Reported-by: NJianlin Shi <jishi@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      929fc032
  22. 27 10月, 2017 2 次提交
  23. 01 10月, 2017 1 次提交
  24. 20 9月, 2017 1 次提交
    • E
      ipv6: speedup ipv6 tunnels dismantle · bb401cae
      Eric Dumazet 提交于
      Implement exit_batch() method to dismantle more devices
      per round.
      
      (rtnl_lock() ...
       unregister_netdevice_many() ...
       rtnl_unlock())
      
      Tested:
      $ cat add_del_unshare.sh
      for i in `seq 1 40`
      do
       (for j in `seq 1 100` ; do unshare -n /bin/true >/dev/null ; done) &
      done
      wait ; grep net_namespace /proc/slabinfo
      
      Before patch :
      $ time ./add_del_unshare.sh
      net_namespace        110    267   5504    1    2 : tunables    8    4    0 : slabdata    110    267      0
      
      real    3m25.292s
      user    0m0.644s
      sys     0m40.153s
      
      After patch:
      
      $ time ./add_del_unshare.sh
      net_namespace        126    282   5504    1    2 : tunables    8    4    0 : slabdata    126    282      0
      
      real	1m38.965s
      user	0m0.688s
      sys	0m37.017s
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb401cae
  25. 19 9月, 2017 1 次提交
    • X
      ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header · 76cc0d32
      Xin Long 提交于
      Now in ip6gre_header before packing the ipv6 header, it skb_push t->hlen
      which only includes encap_hlen + tun_hlen. It means greh and inner header
      would be over written by ipv6 stuff and ipv6h might have no chance to set
      up.
      
      Jianlin found this issue when using remote any on ip6_gre, the packets he
      captured on gre dev are truncated:
      
      22:50:26.210866 Out ethertype IPv6 (0x86dd), length 120: truncated-ip6 -\
      8128 bytes missing!(flowlabel 0x92f40, hlim 0, next-header Options (0)  \
      payload length: 8192) ::1:2000:0 > ::1:0:86dd: HBH [trunc] ip-proto-128 \
      8184
      
      It should also skb_push ipv6hdr so that ipv6h points to the right position
      to set ipv6 stuff up.
      
      This patch is to skb_push hlen + sizeof(*ipv6h) and also fix some indents
      in ip6gre_header.
      
      Fixes: c12b395a ("gre: Support GRE over IPv6")
      Reported-by: NJianlin Shi <jishi@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      76cc0d32
  26. 08 9月, 2017 1 次提交
    • X
      ip6_gre: update mtu properly in ip6gre_err · 5c25f30c
      Xin Long 提交于
      Now when probessing ICMPV6_PKT_TOOBIG, ip6gre_err only subtracts the
      offset of gre header from mtu info. The expected mtu of gre device
      should also subtract gre header. Otherwise, the next packets still
      can't be sent out.
      
      Jianlin found this issue when using the topo:
        client(ip6gre)<---->(nic1)route(nic2)<----->(ip6gre)server
      
      and reducing nic2's mtu, then both tcp and sctp's performance with
      big size data became 0.
      
      This patch is to fix it by also subtracting grehdr (tun->tun_hlen)
      from mtu info when updating gre device's mtu in ip6gre_err(). It
      also needs to subtract ETH_HLEN if gre dev'type is ARPHRD_ETHER.
      Reported-by: NJianlin Shi <jishi@redhat.com>
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c25f30c