linux-stable.git/drivers/net/vxlan, branch v6.4

vxlan: Expose helper vxlan_build_gbp_hdr

2023-03-18T05:41:16+00:00

The function vxlan_build_gbp_hdr will be used by other modules to build
gbp option in vxlan header according to gbp flags.

Signed-off-by: Gavin Li 
Reviewed-by: Gavi Teitz 
Reviewed-by: Roi Dayan 
Reviewed-by: Maor Dickman 
Acked-by: Saeed Mahameed 
Reviewed-by: Simon Horman 
Signed-off-by: Jakub Kicinski

vxlan: Remove unused argument from vxlan_build_gbp_hdr( ) and vxlan_build_gpe_hdr( )

2023-03-18T05:41:16+00:00

Remove unused argument (i.e. u32 vxflags) in vxlan_build_gbp_hdr( ) and
vxlan_build_gpe_hdr( ) function arguments.

Signed-off-by: Gavin Li 
Reviewed-by: Simon Horman 
Signed-off-by: Jakub Kicinski

vxlan: Enable MDB support

2023-03-17T08:05:50+00:00

Now that the VXLAN MDB control and data paths are in place we can expose
the VXLAN MDB functionality to user space.

Set the VXLAN MDB net device operations to the appropriate functions,
thereby allowing the rtnetlink code to reach the VXLAN driver.

Signed-off-by: Ido Schimmel 
Reviewed-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

vxlan: Add MDB data path support

2023-03-17T08:05:50+00:00

Integrate MDB support into the Tx path of the VXLAN driver, allowing it
to selectively forward IP multicast traffic according to the matched MDB
entry.

If MDB entries are configured (i.e., 'VXLAN_F_MDB' is set) and the
packet is an IP multicast packet, perform up to three different lookups
according to the following priority:

1. For an (S, G) entry, using {Source VNI, Source IP, Destination IP}.
2. For a (*, G) entry, using {Source VNI, Destination IP}.
3. For the catchall MDB entry (0.0.0.0 or ::), using the source VNI.

The catchall MDB entry is similar to the catchall FDB entry
(00:00:00:00:00:00) that is currently used to transmit BUM (broadcast,
unknown unicast and multicast) traffic. However, unlike the catchall FDB
entry, this entry is only used to transmit unregistered IP multicast
traffic that is not link-local. Therefore, when configured, the catchall
FDB entry will only transmit BULL (broadcast, unknown unicast,
link-local multicast) traffic.

The catchall MDB entry is useful in deployments where inter-subnet
multicast forwarding is used and not all the VTEPs in a tenant domain
are members in all the broadcast domains. In such deployments it is
advantageous to transmit BULL (broadcast, unknown unicast and link-local
multicast) and unregistered IP multicast traffic on different tunnels.
If the same tunnel was used, a VTEP only interested in IP multicast
traffic would also pull all the BULL traffic and drop it as it is not a
member in the originating broadcast domain [1].

If the packet did not match an MDB entry (or if the packet is not an IP
multicast packet), return it to the Tx path, allowing it to be forwarded
according to the FDB.

If the packet did match an MDB entry, forward it to the associated
remote VTEPs. However, if the entry is a (*, G) entry and the associated
remote is in INCLUDE mode, then skip over it as the source IP is not in
its source list (otherwise the packet would have matched on an (S, G)
entry). Similarly, if the associated remote is marked as BLOCKED (can
only be set on (S, G) entries), then skip over it as well as the remote
is in EXCLUDE mode and the source IP is in its source list.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-2.6

Signed-off-by: Ido Schimmel 
Reviewed-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

vxlan: mdb: Add an internal flag to indicate MDB usage

2023-03-17T08:05:49+00:00

Add an internal flag to indicate whether MDB entries are configured or
not. Set the flag after installing the first MDB entry and clear it
before deleting the last one.

The flag will be consulted by the data path which will only perform an
MDB lookup if the flag is set, thereby keeping the MDB overhead to a
minimum when the MDB is not used.

Another option would have been to use a static key, but it is global and
not per-device, unlike the current approach.

Signed-off-by: Ido Schimmel 
Reviewed-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

vxlan: mdb: Add MDB control path support

2023-03-17T08:05:49+00:00

Implement MDB control path support, enabling the creation, deletion,
replacement and dumping of MDB entries in a similar fashion to the
bridge driver. Unlike the bridge driver, each entry stores a list of
remote VTEPs to which matched packets need to be replicated to and not a
list of bridge ports.

The motivating use case is the installation of MDB entries by a user
space control plane in response to received EVPN routes. As such, only
allow permanent MDB entries to be installed and do not implement
snooping functionality, avoiding a lot of unnecessary complexity.

Since entries can only be modified by user space under RTNL, use RTNL as
the write lock. Use RCU to ensure that MDB entries and remotes are not
freed while being accessed from the data path during transmission.

In terms of uAPI, reuse the existing MDB netlink interface, but add a
few new attributes to request and response messages:

* IP address of the destination VXLAN tunnel endpoint where the
  multicast receivers reside.

* UDP destination port number to use to connect to the remote VXLAN
  tunnel endpoint.

* VXLAN VNI Network Identifier to use to connect to the remote VXLAN
  tunnel endpoint. Required when Ingress Replication (IR) is used and
  the remote VTEP is not a member of originating broadcast domain
  (VLAN/VNI) [1].

* Source VNI Network Identifier the MDB entry belongs to. Used only when
  the VXLAN device is in external mode.

* Interface index of the outgoing interface to reach the remote VXLAN
  tunnel endpoint. This is required when the underlay destination IP is
  multicast (P2MP), as the multicast routing tables are not consulted.

All the new attributes are added under the 'MDBA_SET_ENTRY_ATTRS' nest
which is strictly validated by the bridge driver, thereby automatically
rejecting the new attributes.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-3.2.2

Signed-off-by: Ido Schimmel 
Reviewed-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

vxlan: Expose vxlan_xmit_one()

2023-03-17T08:05:49+00:00

Given a packet and a remote destination, the function will take care of
encapsulating the packet and transmitting it to the destination.

Expose it so that it could be used in subsequent patches by the MDB code
to transmit a packet to the remote destination(s) stored in the MDB
entry.

It will allow us to keep the MDB code self-contained, not exposing its
data structures to the rest of the VXLAN driver.

Signed-off-by: Ido Schimmel 
Reviewed-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

vxlan: Move address helpers to private headers

2023-03-17T08:05:49+00:00

Move the helpers out of the core C file to the private header so that
they could be used by the upcoming MDB code.

While at it, constify the second argument of vxlan_nla_get_addr().

Signed-off-by: Ido Schimmel 
Reviewed-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller

neighbour: annotate lockless accesses to n->nud_state

2023-03-15T07:37:32+00:00

We have many lockless accesses to n->nud_state.

Before adding another one in the following patch,
add annotations to readers and writers.

Signed-off-by: Eric Dumazet 
Reviewed-by: David Ahern 
Reviewed-by: Martin KaFai Lau 
Signed-off-by: Jakub Kicinski

vxlan: Fix memory leaks in error path

2023-01-02T13:37:33+00:00

The memory allocated by vxlan_vnigroup_init() is not freed in the error
path, leading to memory leaks [1]. Fix by calling
vxlan_vnigroup_uninit() in the error path.

The leaks can be reproduced by annotating gro_cells_init() with
ALLOW_ERROR_INJECTION() and then running:

 # echo "100" > /sys/kernel/debug/fail_function/probability
 # echo "1" > /sys/kernel/debug/fail_function/times
 # echo "gro_cells_init" > /sys/kernel/debug/fail_function/inject
 # printf %#x -12 > /sys/kernel/debug/fail_function/gro_cells_init/retval
 # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter
 RTNETLINK answers: Cannot allocate memory

[1]
unreferenced object 0xffff88810db84a00 (size 512):
  comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
  hex dump (first 32 bytes):
    f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02  ..v.............
    03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00  ....H...........
  backtrace:
    [] kmalloc_trace+0x2a/0x60
    [] vxlan_vnigroup_init+0x4c/0x160
    [] vxlan_init+0x1ae/0x280
    [] register_netdevice+0x57a/0x16d0
    [] __vxlan_dev_create+0x7c7/0xa50
    [] vxlan_newlink+0xd6/0x130
    [] __rtnl_newlink+0x112b/0x18a0
    [] rtnl_newlink+0x6c/0xa0
    [] rtnetlink_rcv_msg+0x43f/0xd40
    [] netlink_rcv_skb+0x170/0x440
    [] netlink_unicast+0x53f/0x810
    [] netlink_sendmsg+0x958/0xe70
    [] ____sys_sendmsg+0x78f/0xa90
    [] ___sys_sendmsg+0x13a/0x1e0
    [] __sys_sendmsg+0x11c/0x1f0
    [] do_syscall_64+0x38/0x80
unreferenced object 0xffff88810e76d5f8 (size 192):
  comm "ip", pid 330, jiffies 4295010045 (age 66.016s)
  hex dump (first 32 bytes):
    04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00  ..........O.....
    08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff  ..v.......v.....
  backtrace:
    [] __kmalloc_node+0x4e/0x90
    [] kvmalloc_node+0xa6/0x1f0
    [] bucket_table_alloc.isra.0+0x83/0x460
    [] rhashtable_init+0x43b/0x7c0
    [] vxlan_vnigroup_init+0x6c/0x160
    [] vxlan_init+0x1ae/0x280
    [] register_netdevice+0x57a/0x16d0
    [] __vxlan_dev_create+0x7c7/0xa50
    [] vxlan_newlink+0xd6/0x130
    [] __rtnl_newlink+0x112b/0x18a0
    [] rtnl_newlink+0x6c/0xa0
    [] rtnetlink_rcv_msg+0x43f/0xd40
    [] netlink_rcv_skb+0x170/0x440
    [] netlink_unicast+0x53f/0x810
    [] netlink_sendmsg+0x958/0xe70
    [] ____sys_sendmsg+0x78f/0xa90

Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device")
Signed-off-by: Ido Schimmel 
Reviewed-by: Nikolay Aleksandrov 
Signed-off-by: David S. Miller