1. 28 4月, 2022 1 次提交
    • L
      ipvlan: Modify the value of ipvlan modes · 382ceac7
      Lu Wei 提交于
      hulk inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I52H2U
      CVE: NA
      
      --------------------------------
      
      The L2E mode of ipvlan is introduced in 4.19, and the mode value
      IPVLAN_MODE_L2E is inserted between IPVLAN_MODE_L3 and IPVLAN_MODE_L3S
      in enum ipvlan_mode as follows:
      	enum ipvlan_mode {
      		IPVLAN_MODE_L2 = 0,
      		IPVLAN_MODE_L3,
      	      + IPVLAN_MODE_L2E,
      		IPVLAN_MODE_L3S,
      		IPVLAN_MODE_MAX
      	};
      
      that means the value of IPVLAN_MODE_L3S is changed from 2 to 3, and
      it is different from other operation system like SUSE, rethad and etc.
      
      In order to fix it, IPVLAN_MODE_L2E is placed behind IPVLAN_MODE_L3S in
      5.10. However it is incompatible with iproute tool since iproute defines
      enum ipvlan_mode as it does in 4.19. So this patch moves the IPVLAN_MODE_L2E
      back to keep incompatible with iproute tool.
      
      Fixes: bd73acb1 ("ipvlan: Introduce l2e mode")
      Signed-off-by: NLu Wei <luwei32@huawei.com>
      Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      382ceac7
  2. 20 1月, 2022 1 次提交
  3. 27 12月, 2021 5 次提交
  4. 25 8月, 2020 1 次提交
    • T
      ipvlan: advertise link netns via netlink · 0bad834c
      Taehee Yoo 提交于
      Assign rtnl_link_ops->get_link_net() callback so that IFLA_LINK_NETNSID is
      added to rtnetlink messages.
      
      Test commands:
          ip netns add nst
          ip link add dummy0 type dummy
          ip link add ipvlan0 link dummy0 type ipvlan
          ip link set ipvlan0 netns nst
          ip netns exec nst ip link show ipvlan0
      
      Result:
          ---Before---
          6: ipvlan0@if5: <BROADCAST,MULTICAST> ...
              link/ether 82:3a:78:ab:60:50 brd ff:ff:ff:ff:ff:ff
      
          ---After---
          12: ipvlan0@if11: <BROADCAST,MULTICAST> ...
              link/ether 42:b1:ad:57:4e:27 brd ff:ff:ff:ff:ff:ff link-netnsid 0
                                                                 ~~~~~~~~~~~~~~
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bad834c
  5. 17 8月, 2020 1 次提交
    • M
      ipvlan: fix device features · d0f5c707
      Mahesh Bandewar 提交于
      Processing NETDEV_FEAT_CHANGE causes IPvlan links to lose
      NETIF_F_LLTX feature because of the incorrect handling of
      features in ipvlan_fix_features().
      
      --before--
      lpaa10:~# ethtool -k ipvl0 | grep tx-lockless
      tx-lockless: on [fixed]
      lpaa10:~# ethtool -K ipvl0 tso off
      Cannot change tcp-segmentation-offload
      Actual changes:
      vlan-challenged: off [fixed]
      tx-lockless: off [fixed]
      lpaa10:~# ethtool -k ipvl0 | grep tx-lockless
      tx-lockless: off [fixed]
      lpaa10:~#
      
      --after--
      lpaa10:~# ethtool -k ipvl0 | grep tx-lockless
      tx-lockless: on [fixed]
      lpaa10:~# ethtool -K ipvl0 tso off
      Cannot change tcp-segmentation-offload
      Could not change any device features
      lpaa10:~# ethtool -k ipvl0 | grep tx-lockless
      tx-lockless: on [fixed]
      lpaa10:~#
      
      Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.")
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0f5c707
  6. 05 5月, 2020 1 次提交
  7. 09 3月, 2020 1 次提交
    • J
      ipvlan: do not add hardware address of master to its unicast filter list · 63aae7b1
      Jiri Wiesner 提交于
      There is a problem when ipvlan slaves are created on a master device that
      is a vmxnet3 device (ipvlan in VMware guests). The vmxnet3 driver does not
      support unicast address filtering. When an ipvlan device is brought up in
      ipvlan_open(), the ipvlan driver calls dev_uc_add() to add the hardware
      address of the vmxnet3 master device to the unicast address list of the
      master device, phy_dev->uc. This inevitably leads to the vmxnet3 master
      device being forced into promiscuous mode by __dev_set_rx_mode().
      
      Promiscuous mode is switched on the master despite the fact that there is
      still only one hardware address that the master device should use for
      filtering in order for the ipvlan device to be able to receive packets.
      The comment above struct net_device describes the uc_promisc member as a
      "counter, that indicates, that promiscuous mode has been enabled due to
      the need to listen to additional unicast addresses in a device that does
      not implement ndo_set_rx_mode()". Moreover, the design of ipvlan
      guarantees that only the hardware address of a master device,
      phy_dev->dev_addr, will be used to transmit and receive all packets from
      its ipvlan slaves. Thus, the unicast address list of the master device
      should not be modified by ipvlan_open() and ipvlan_stop() in order to make
      ipvlan a workable option on masters that do not support unicast address
      filtering.
      
      Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver")
      Reported-by: NPer Sundstrom <per.sundstrom@redqube.se>
      Signed-off-by: NJiri Wiesner <jwiesner@suse.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63aae7b1
  8. 25 10月, 2019 1 次提交
    • T
      net: core: add generic lockdep keys · ab92d68f
      Taehee Yoo 提交于
      Some interface types could be nested.
      (VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI, VXLAN, etc..)
      These interface types should set lockdep class because, without lockdep
      class key, lockdep always warn about unexisting circular locking.
      
      In the current code, these interfaces have their own lockdep class keys and
      these manage itself. So that there are so many duplicate code around the
      /driver/net and /net/.
      This patch adds new generic lockdep keys and some helper functions for it.
      
      This patch does below changes.
      a) Add lockdep class keys in struct net_device
         - qdisc_running, xmit, addr_list, qdisc_busylock
         - these keys are used as dynamic lockdep key.
      b) When net_device is being allocated, lockdep keys are registered.
         - alloc_netdev_mqs()
      c) When net_device is being free'd llockdep keys are unregistered.
         - free_netdev()
      d) Add generic lockdep key helper function
         - netdev_register_lockdep_key()
         - netdev_unregister_lockdep_key()
         - netdev_update_lockdep_key()
      e) Remove unnecessary generic lockdep macro and functions
      f) Remove unnecessary lockdep code of each interfaces.
      
      After this patch, each interface modules don't need to maintain
      their lockdep keys.
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab92d68f
  9. 11 10月, 2019 1 次提交
  10. 17 8月, 2019 1 次提交
  11. 05 6月, 2019 1 次提交
  12. 31 5月, 2019 1 次提交
  13. 23 2月, 2019 1 次提交
    • D
      ipvlan: disallow userns cap_net_admin to change global mode/flags · 7cc9f700
      Daniel Borkmann 提交于
      When running Docker with userns isolation e.g. --userns-remap="default"
      and spawning up some containers with CAP_NET_ADMIN under this realm, I
      noticed that link changes on ipvlan slave device inside that container
      can affect all devices from this ipvlan group which are in other net
      namespaces where the container should have no permission to make changes
      to, such as the init netns, for example.
      
      This effectively allows to undo ipvlan private mode and switch globally to
      bridge mode where slaves can communicate directly without going through
      hostns, or it allows to switch between global operation mode (l2/l3/l3s)
      for everyone bound to the given ipvlan master device. libnetwork plugin
      here is creating an ipvlan master and ipvlan slave in hostns and a slave
      each that is moved into the container's netns upon creation event.
      
      * In hostns:
      
        # ip -d a
        [...]
        8: cilium_host@bond0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
           link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
           ipvlan  mode l3 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
           inet 10.41.0.1/32 scope link cilium_host
             valid_lft forever preferred_lft forever
        [...]
      
      * Spawn container & change ipvlan mode setting inside of it:
      
        # docker run -dt --cap-add=NET_ADMIN --network cilium-net --name client -l app=test cilium/netperf
        9fff485d69dcb5ce37c9e33ca20a11ccafc236d690105aadbfb77e4f4170879c
      
        # docker exec -ti client ip -d a
        [...]
        10: cilium0@if4: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
            link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
            ipvlan  mode l3 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
            inet 10.41.197.43/32 brd 10.41.197.43 scope global cilium0
               valid_lft forever preferred_lft forever
      
        # docker exec -ti client ip link change link cilium0 name cilium0 type ipvlan mode l2
      
        # docker exec -ti client ip -d a
        [...]
        10: cilium0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
            link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
            ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
            inet 10.41.197.43/32 brd 10.41.197.43 scope global cilium0
               valid_lft forever preferred_lft forever
      
      * In hostns (mode switched to l2):
      
        # ip -d a
        [...]
        8: cilium_host@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
            link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
            ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
            inet 10.41.0.1/32 scope link cilium_host
               valid_lft forever preferred_lft forever
        [...]
      
      Same l3 -> l2 switch would also happen by creating another slave inside
      the container's network namespace when specifying the existing cilium0
      link to derive the actual (bond0) master:
      
        # docker exec -ti client ip link add link cilium0 name cilium1 type ipvlan mode l2
      
        # docker exec -ti client ip -d a
        [...]
        2: cilium1@if4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
            link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
            ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
        10: cilium0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
            link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
            ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
            inet 10.41.197.43/32 brd 10.41.197.43 scope global cilium0
               valid_lft forever preferred_lft forever
      
      * In hostns:
      
        # ip -d a
        [...]
        8: cilium_host@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
            link/ether 0c:c4:7a:e1:3d:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
            ipvlan  mode l2 bridge numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
            inet 10.41.0.1/32 scope link cilium_host
               valid_lft forever preferred_lft forever
        [...]
      
      One way to mitigate it is to check CAP_NET_ADMIN permissions of
      the ipvlan master device's ns, and only then allow to change
      mode or flags for all devices bound to it. Above two cases are
      then disallowed after the patch.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7cc9f700
  14. 09 2月, 2019 1 次提交
    • D
      ipvlan: decouple l3s mode dependencies from other modes · c675e06a
      Daniel Borkmann 提交于
      Right now ipvlan has a hard dependency on CONFIG_NETFILTER and
      otherwise it cannot be built. However, the only ipvlan operation
      mode that actually depends on netfilter is l3s, everything else
      is independent of it. Break this hard dependency such that users
      are able to use ipvlan l3 mode on systems where netfilter is not
      compiled in.
      
      Therefore, this adds a hidden CONFIG_IPVLAN_L3S bool which is
      defaulting to y when CONFIG_NETFILTER is set in order to retain
      existing behavior for l3s. All l3s related code is refactored
      into ipvlan_l3s.c that is compiled in when enabled.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Martynas Pumputis <m@lambda.lt>
      Acked-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c675e06a
  15. 31 1月, 2019 1 次提交
    • D
      ipvlan, l3mdev: fix broken l3s mode wrt local routes · d5256083
      Daniel Borkmann 提交于
      While implementing ipvlan l3 and l3s mode for kubernetes CNI plugin,
      I ran into the issue that while l3 mode is working fine, l3s mode
      does not have any connectivity to kube-apiserver and hence all pods
      end up in Error state as well. The ipvlan master device sits on
      top of a bond device and hostns traffic to kube-apiserver (also running
      in hostns) is DNATed from 10.152.183.1:443 to 139.178.29.207:37573
      where the latter is the address of the bond0. While in l3 mode, a
      curl to https://10.152.183.1:443 or to https://139.178.29.207:37573
      works fine from hostns, neither of them do in case of l3s. In the
      latter only a curl to https://127.0.0.1:37573 appeared to work where
      for local addresses of bond0 I saw kernel suddenly starting to emit
      ARP requests to query HW address of bond0 which remained unanswered
      and neighbor entries in INCOMPLETE state. These ARP requests only
      happen while in l3s.
      
      Debugging this further, I found the issue is that l3s mode is piggy-
      backing on l3 master device, and in this case local routes are using
      l3mdev_master_dev_rcu(dev) instead of net->loopback_dev as per commit
      f5a0aab8 ("net: ipv4: dst for local input routes should use l3mdev
      if relevant") and 5f02ce24 ("net: l3mdev: Allow the l3mdev to be
      a loopback"). I found that reverting them back into using the
      net->loopback_dev fixed ipvlan l3s connectivity and got everything
      working for the CNI.
      
      Now judging from 4fbae7d8 ("ipvlan: Introduce l3s mode") and the
      l3mdev paper in [0] the only sole reason why ipvlan l3s is relying
      on l3 master device is to get the l3mdev_ip_rcv() receive hook for
      setting the dst entry of the input route without adding its own
      ipvlan specific hacks into the receive path, however, any l3 domain
      semantics beyond just that are breaking l3s operation. Note that
      ipvlan also has the ability to dynamically switch its internal
      operation from l3 to l3s for all ports via ipvlan_set_port_mode()
      at runtime. In any case, l3 vs l3s soley distinguishes itself by
      'de-confusing' netfilter through switching skb->dev to ipvlan slave
      device late in NF_INET_LOCAL_IN before handing the skb to L4.
      
      Minimal fix taken here is to add a IFF_L3MDEV_RX_HANDLER flag which,
      if set from ipvlan setup, gets us only the wanted l3mdev_l3_rcv() hook
      without any additional l3mdev semantics on top. This should also have
      minimal impact since dev->priv_flags is already hot in cache. With
      this set, l3s mode is working fine and I also get things like
      masquerading pod traffic on the ipvlan master properly working.
      
        [0] https://netdevconf.org/1.2/papers/ahern-what-is-l3mdev-paper.pdf
      
      Fixes: f5a0aab8 ("net: ipv4: dst for local input routes should use l3mdev if relevant")
      Fixes: 5f02ce24 ("net: l3mdev: Allow the l3mdev to be a loopback")
      Fixes: 4fbae7d8 ("ipvlan: Introduce l3s mode")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Cc: David Ahern <dsa@cumulusnetworks.com>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Martynas Pumputis <m@lambda.lt>
      Acked-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5256083
  16. 14 12月, 2018 1 次提交
  17. 11 12月, 2018 1 次提交
  18. 07 12月, 2018 2 次提交
  19. 02 7月, 2018 1 次提交
    • H
      ipvlan: call dev_change_flags when ipvlan mode is reset · 5dc2d399
      Hangbin Liu 提交于
      After we change the ipvlan mode from l3 to l2, or vice versa, we only
      reset IFF_NOARP flag, but don't flush the ARP table cache, which will
      cause eth->h_dest to be equal to eth->h_source in ipvlan_xmit_mode_l2().
      Then the message will not come out of host.
      
      Here is the reproducer on local host:
      
      ip link set eth1 up
      ip addr add 192.168.1.1/24 dev eth1
      ip link add link eth1 ipvlan1 type ipvlan mode l3
      
      ip netns add net1
      ip link set ipvlan1 netns net1
      ip netns exec net1 ip link set ipvlan1 up
      ip netns exec net1 ip addr add 192.168.2.1/24 dev ipvlan1
      
      ip route add 192.168.2.0/24 via 192.168.1.2
      ping 192.168.2.2 -c 2
      
      ip netns exec net1 ip link set ipvlan1 type ipvlan mode l2
      ping 192.168.2.2 -c 2
      
      Add the same configuration on remote host. After we set the mode to l2,
      we could find that the src/dst MAC addresses are the same on eth1:
      
      21:26:06.648565 00:b7:13:ad:d3:05 > 00:b7:13:ad:d3:05, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 58356, offset 0, flags [DF], proto ICMP (1), length 84)
          192.168.2.1 > 192.168.2.2: ICMP echo request, id 22686, seq 1, length 64
      
      Fix this by calling dev_change_flags(), which will call netdevice notifier
      with flag change info.
      
      v2:
      a) As pointed out by Wang Cong, check return value for dev_change_flags() when
      change dev flags.
      b) As suggested by Stefano and Sabrina, move flags setting before l3mdev_ops.
      So we don't need to redo ipvlan_{, un}register_nf_hook() again in err path.
      Reported-by: NJianlin Shi <jishi@redhat.com>
      Reviewed-by: NStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: NSabrina Dubroca <sd@queasysnail.net>
      Fixes: 2ad7bf36 ("ipvlan: Initial check-in of the IPVLAN driver.")
      Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5dc2d399
  20. 21 6月, 2018 1 次提交
  21. 20 6月, 2018 1 次提交
  22. 16 5月, 2018 1 次提交
  23. 28 3月, 2018 1 次提交
  24. 10 3月, 2018 1 次提交
    • P
      net: introduce IFF_NO_RX_HANDLER · f5426250
      Paolo Abeni 提交于
      Some network devices - notably ipvlan slave - are not compatible with
      any kind of rx_handler. Currently the hook can be installed but any
      configuration (bridge, bond, macsec, ...) is nonfunctional.
      
      This change allocates a priv_flag bit to mark such devices and explicitly
      forbid installing a rx_handler if such bit is set. The new bit is used
      by ipvlan slave device.
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5426250
  25. 08 3月, 2018 1 次提交
    • P
      net: unpollute priv_flags space · 1ec54cb4
      Paolo Abeni 提交于
      the ipvlan device driver defines and uses 2 bits inside the priv_flags
      net_device field. Such bits and the related helper are used only
      inside the ipvlan device driver, and the core networking does not
      need to be aware of them.
      
      This change moves netif_is_ipvlan* helper in the ipvlan driver and
      re-implement them looking for ipvlan specific symbols instead of
      using priv_flags.
      
      Overall this frees two bits inside priv_flags - and move the following
      ones to avoid gaps - without any intended functional change.
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ec54cb4
  26. 05 3月, 2018 1 次提交
  27. 01 3月, 2018 1 次提交
    • P
      ipvlan: use per device spinlock to protect addrs list updates · 82308194
      Paolo Abeni 提交于
      This changeset moves ipvlan address under RCU protection, using
      a per ipvlan device spinlock to protect list mutation and RCU
      read access to protect list traversal.
      
      Also explicitly use RCU read lock to traverse the per port
      ipvlans list, so that we can now perform a full address lookup
      without asserting the RTNL lock.
      
      Overall this allows the ipvlan driver to check fully for duplicate
      addresses - before this commit ipv6 addresses assigned by autoconf
      via prefix delegation where accepted without any check - and avoid
      the following rntl assertion failure still in the same code path:
      
       RTNL: assertion failed at drivers/net/ipvlan/ipvlan_core.c (124)
       WARNING: CPU: 15 PID: 0 at drivers/net/ipvlan/ipvlan_core.c:124 ipvlan_addr_busy+0x97/0xa0 [ipvlan]
       Modules linked in: ipvlan(E) ixgbe
       CPU: 15 PID: 0 Comm: swapper/15 Tainted: G            E    4.16.0-rc2.ipvlan+ #1782
       Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.1.7 06/16/2016
       RIP: 0010:ipvlan_addr_busy+0x97/0xa0 [ipvlan]
       RSP: 0018:ffff881ff9e03768 EFLAGS: 00010286
       RAX: 0000000000000000 RBX: ffff881fdf2a9000 RCX: 0000000000000000
       RDX: 0000000000000001 RSI: 00000000000000f6 RDI: 0000000000000300
       RBP: ffff881fdf2a8000 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000001 R11: ffff881ff9e034c0 R12: ffff881fe07bcc00
       R13: 0000000000000001 R14: ffffffffa02002b0 R15: 0000000000000001
       FS:  0000000000000000(0000) GS:ffff881ff9e00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007fc5c1a4f248 CR3: 000000207e012005 CR4: 00000000001606e0
       Call Trace:
        <IRQ>
        ipvlan_addr6_event+0x6c/0xd0 [ipvlan]
        notifier_call_chain+0x49/0x90
        atomic_notifier_call_chain+0x6a/0x100
        ipv6_add_addr+0x5f9/0x720
        addrconf_prefix_rcv_add_addr+0x244/0x3c0
        addrconf_prefix_rcv+0x2f3/0x790
        ndisc_router_discovery+0x633/0xb70
        ndisc_rcv+0x155/0x180
        icmpv6_rcv+0x4ac/0x5f0
        ip6_input_finish+0x138/0x6a0
        ip6_input+0x41/0x1f0
        ipv6_rcv+0x4db/0x8d0
        __netif_receive_skb_core+0x3d5/0xe40
        netif_receive_skb_internal+0x89/0x370
        napi_gro_receive+0x14f/0x1e0
        ixgbe_clean_rx_irq+0x4ce/0x1020 [ixgbe]
        ixgbe_poll+0x31a/0x7a0 [ixgbe]
        net_rx_action+0x296/0x4f0
        __do_softirq+0xcf/0x4f5
        irq_exit+0xf5/0x110
        do_IRQ+0x62/0x110
        common_interrupt+0x91/0x91
        </IRQ>
      
       v1 -> v2: drop unneeded in_softirq check in ipvlan_addr6_validator_event()
      
      Fixes: e9997c29 ("ipvlan: fix check for IP addresses in control path")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      82308194
  28. 28 2月, 2018 1 次提交
    • K
      net: Convert ipvlan_net_ops · 68eabe8b
      Kirill Tkhai 提交于
      These pernet_operations unregister ipvlan net hooks.
      nf_unregister_net_hooks() removes hooks one-by-one,
      and then frees the memory via rcu. This looks similar
      to that happens, when a new hooks is added: allocation
      of bigger memory region, copy of old content, and rcu
      freeing the old memory. So, all of net code should be
      well with this behavior. Also at the time of hook
      unregistering, there are no packets, and foreign net
      pernet_operations are not interested in others hooks.
      So, we mark them as async.
      Signed-off-by: NKirill Tkhai <ktkhai@virtuozzo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68eabe8b
  29. 22 2月, 2018 1 次提交
  30. 03 12月, 2017 1 次提交
  31. 18 11月, 2017 1 次提交
  32. 29 10月, 2017 2 次提交
    • M
      ipvlan: implement VEPA mode · fe89aa6b
      Mahesh Bandewar 提交于
      This is very similar to the Macvlan VEPA mode, however, there is some
      difference. IPvlan uses the mac-address of the lower device, so the VEPA
      mode has implications of ICMP-redirects for packets destined for its
      immediate neighbors sharing same master since the packets will have same
      source and dest mac. The external switch/router will send redirect msg.
      
      Having said that, this will be useful tool in terms of debugging
      since IPvlan will not switch packets within its slaves and rely completely
      on the external entity as intended in 802.1Qbg.
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fe89aa6b
    • M
      ipvlan: introduce 'private' attribute for all existing modes. · a190d04d
      Mahesh Bandewar 提交于
      IPvlan has always operated in bridge mode. However there are scenarios
      where each slave should be able to talk through the master device but
      not necessarily across each other. Think of an environment where each
      of a namespace is a private and independant customer. In this scenario
      the machine which is hosting these namespaces neither want to tell who
      their neighbor is nor the individual namespaces care to talk to neighbor
      on short-circuited network path.
      
      This patch implements the mode that is very similar to the 'private' mode
      in macvlan where individual slaves can send and receive traffic through
      the master device, just that they can not talk among slave devices.
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a190d04d
  33. 20 10月, 2017 2 次提交