lagg: Use static initializers

MFC after: 1 week

lagg: do not advertize support for ipsec offload

It is not implemented, and most likely cannot be, in a robust manner.

Reviewed by: Ariel Ehrenberg <aehrenberg@nvidia.com>, slavash
Sponsored by: NV

lagg: do not advertize support for ipsec offload

It is not implemented, and most likely cannot be, in a robust manner.

Reviewed by: Ariel Ehrenberg <aehrenberg@nvidia.com>, slavash
Sponsored by: NVidia networking

show more ...

net/if_lagg.c: remove stray include is sys/cdefs.h

Sponsored by: NVidia networking

net: Remove unneeded NULL check for the allocated ifnet

Change 4787572d0580 made if_alloc_domain() never fail, then also do the
wrappers if_alloc(), if_alloc_dev(), and if_gethandle().

No functiona

net: Remove unneeded NULL check for the allocated ifnet

Change 4787572d0580 made if_alloc_domain() never fail, then also do the
wrappers if_alloc(), if_alloc_dev(), and if_gethandle().

No functional change intended.

Reviewed by: kp, imp, glebius, stevek
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D45740

show more ...

lagg: Fix a teardown race

When a lagg interface is destroyed, it destroys all of the lagg ports,
which triggers an asynchronous link state change handler. This in turn
may generate a netlink messag

lagg: Fix a teardown race

When a lagg interface is destroyed, it destroys all of the lagg ports,
which triggers an asynchronous link state change handler. This in turn
may generate a netlink message, a portion of which requires netlink to
invoke the SIOCGIFMEDIA ioctl of the lagg interface, which involves
scanning the list of interface media. This list is not internally
locked, it requires the interface driver to provide some kind of
synchronization.

Shortly after the link state notification has been raised, the lagg
interface detaches itself from the network stack. As a part of this, it
blocks in order to wait for link state handlers to drain, but before
that it destroys the interface media list. Reverse this order of
operations so that the link state change handlers drain first, avoiding
a use-after-free that is very occasionally triggered by lagg stress
tests. This matches other ethernet drivers in the tree.

MFC after: 2 weeks

show more ...

lagg: remove use of net epoch in the ioctl paths

Rely on LAGG_SLOCK() instead. The use of network epoch(9) here was added
in 6573d7580b851 (later tidied by 87bf9b9cbeebc) as a large sweep that
blin

lagg: remove use of net epoch in the ioctl paths

Rely on LAGG_SLOCK() instead. The use of network epoch(9) here was added
in 6573d7580b851 (later tidied by 87bf9b9cbeebc) as a large sweep that
blindly substituted blocking kernel primitives with epoch(9). In these
particular code paths use of epoch(9) is incorrect and doesn't provide any
protection against a stale pointer. Recent fix 48698ead6ff0, which should
actually have removed the epoch use, created a potential sleeping in epoch
problem.

show more ...

lagg: propagate up/down to the children

Based on the old submission from asomers@. With modern state of locking
in lagg(4), the patch got much simplier. Enable the test that was
waiting for this c

lagg: propagate up/down to the children

Based on the old submission from asomers@. With modern state of locking
in lagg(4), the patch got much simplier. Enable the test that was
waiting for this change.

PR: 226144
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D44605

show more ...

lagg: wrap lagg_port2req() into LAGG_SLOCK()

Although a port addition is coded in a sequence where first all softc
information is fulfilled and only then it is attached to the lagg, we
still need a

lagg: wrap lagg_port2req() into LAGG_SLOCK()

Although a port addition is coded in a sequence where first all softc
information is fulfilled and only then it is attached to the lagg, we
still need a locking primitive to guarantee cache invalidation. Panic
observed in the wild shows that lacp_portreq() called via
lagg_port_ioctl(SIOCGLAGGPORT) immediately after port creation may see
lp->lp_psc as NULL and panic. In the core file we will see valid data
all around. A race via lagg_ioctl() wasn't observed but potentially
is possible.

Differential Revision: https://reviews.freebsd.org/D43501

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

lagg(4): Correctly define some sysctl variables

939a050ad96c virtualized lagg(4), but the corresponding sysctl of some
virtualized global variables are not marked with CTLFLAG_VNET. A try to
operate

lagg(4): Correctly define some sysctl variables

939a050ad96c virtualized lagg(4), but the corresponding sysctl of some
virtualized global variables are not marked with CTLFLAG_VNET. A try to
operate on those variables via sysctl will effectively go to the 'master'
copies and the virtualized ones are not read or set accordingly. As a
side effect, on updating the 'master' copy, the virtualized global
variables of newly created vnets will have correct values.

PR: 270705
Reviewed by: kp
Fixes: 939a050ad96c Virtualize lagg(4) cloner
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39467

show more ...

lagg(4): Tap traffic after protocol processing

Different lagg protocols have different means and policies to process incoming
traffic. For example, for failover protocol, by default received traffic

lagg(4): Tap traffic after protocol processing

Different lagg protocols have different means and policies to process incoming
traffic. For example, for failover protocol, by default received traffic is only
accepted when they are received through the active port. For lacp protocol, LACP
control messages are tapped off, also traffic will be dropped if they are
received through the port which is not in collecting state or is not joined to
the active aggregator. It confuses if user dump and see inbound traffic on
lagg(4) interfaces but they are actually silently dropped and not passed into
the net stack.

Tap traffic after protocol processing so that user will have consistent view of
the inbound traffic, meanwhile mbuf is set with correct receiving interface and
bpf(4) will diagnose the right direction of inbound packets.

PR: 270417
Reviewed by: melifaro (previous version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39225

show more ...

infiniband: Widen NET_EPOCH coverage

From static code analysis, some device drivers (cxgbe, mlx4, mthca, and qlnx)
do not enter net epoch before lagg_input_infiniband(). If IPoIB interface is a
memb

infiniband: Widen NET_EPOCH coverage

From static code analysis, some device drivers (cxgbe, mlx4, mthca, and qlnx)
do not enter net epoch before lagg_input_infiniband(). If IPoIB interface is a
member of lagg(4) interface, and after returning from lagg_input_infiniband()
the receiving interface of mbuf is set to lagg(4) interface, then when
concurrently destroying the lagg(4) interface, there is a small window that the
interface gets destroyed and becomes invalid before infiniband_input() re-enter
net epoch, thus leading use-after-free.

Widen NET_EPOCH coverage to prevent use-after-free.

Thanks hselasky@ for testing with mlx5 devices.

Reviewed by: hselasky
Tested by: hselasky
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39275

show more ...

lacp: Use C99 bool for boolean return value

This improves readability.

No functional change intended.

MFC after: 1 week

lagg(4): Do not enter net epoch recursively

This saves a little resources.

No functional change intended.

Reviewed by: kp
Fixes: b8a6e03fac92 Widen NET_EPOCH coverage
MFC after: 1 week
Differenti

lagg(4): Do not enter net epoch recursively

This saves a little resources.

No functional change intended.

Reviewed by: kp
Fixes: b8a6e03fac92 Widen NET_EPOCH coverage
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39267

show more ...

lagg(4): Refactor out some lagg protocol input routines into a default one

Those input routines are identical.

Also inline two fast paths.

No functional change intended.

MFC after: 1 week
Differe

lagg(4): Refactor out some lagg protocol input routines into a default one

Those input routines are identical.

Also inline two fast paths.

No functional change intended.

MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39251

show more ...

lagg(4): Make lagg_list and lagg_detach_cookie static

They are used internally only.

No functional change intended.

MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D39250

lagg: Various style fixes

MFC after: 1 week

infiniband: Convert BPF handling for IfAPI

Summary:
All callers of infiniband_bpf_mtap() call it through the wrapper macro,
which checks the if_bpf member explicitly. Since this is getting
hidden,

infiniband: Convert BPF handling for IfAPI

Summary:
All callers of infiniband_bpf_mtap() call it through the wrapper macro,
which checks the if_bpf member explicitly. Since this is getting
hidden, move this check into the internal function and remove the
wrapper macro.

Reviewed by: hselasky
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D39024

show more ...

net: unify mtu update code

Subscribers: imp, ae, glebius

Differential Revision: https://reviews.freebsd.org/D38893

ifnet/API: Move struct ifnet definition to a <net/if_private.h>

Hide the ifnet structure definition, no user serviceable parts inside,
it's a netstack implementation detail. Include it temporarily

ifnet/API: Move struct ifnet definition to a <net/if_private.h>

Hide the ifnet structure definition, no user serviceable parts inside,
it's a netstack implementation detail. Include it temporarily in
<net/if_var.h> until all drivers are updated to use the accessors
exclusively.

Reviewed by: glebius
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D38046

show more ...

if_lagg: Allow lagg interfaces to be used with netmap

Reviewed by: zlei
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D37

if_lagg: Allow lagg interfaces to be used with netmap

Reviewed by: zlei
Sponsored by: Zenarmor
Sponsored by: OPNsense
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D37436

show more ...

if_clone: migrate some consumers to the new KPI.

Convert most of the cloner customers who require custom params
to the new if_clone KPI.

Reviewed by: kp
Differential Revision: https://reviews.free

if_clone: migrate some consumers to the new KPI.

Convert most of the cloner customers who require custom params
to the new if_clone KPI.

Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D36636
MFC after: 2 weeks

show more ...

lagg: fix lagg ifioctl after SIOCSIFCAPNV

Lagg was broken by SIOCSIFCAPNV when all underlying devices
support SIOCSIFCAPNV. This change updates lagg to work with
SIOCSIFCAPNV and if_capabilities2.

lagg: fix lagg ifioctl after SIOCSIFCAPNV

Lagg was broken by SIOCSIFCAPNV when all underlying devices
support SIOCSIFCAPNV. This change updates lagg to work with
SIOCSIFCAPNV and if_capabilities2.

Reviewed by: kib, hselasky
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D35865

show more ...

Fix unused variable warning in if_lagg.c

With clang 15, the following -Werror warning is produced:

sys/net/if_lagg.c:2413:6: error: variable 'active_ports' set but not used [-Werror,-Wunused-bu

Fix unused variable warning in if_lagg.c

With clang 15, the following -Werror warning is produced:

sys/net/if_lagg.c:2413:6: error: variable 'active_ports' set but not used [-Werror,-Wunused-but-set-variable]
int active_ports = 0;
^

The 'active_ports' variable appears to have been a debugging aid that
has never been used for anything (ref https://reviews.freebsd.org/D549),
so remove it.

MFC after: 3 days

show more ...

lagg(4): Add support for allocating TLS receive tags.

The TLS receive tags are allocated directly from the receiving interface,
because mbufs are flowing in the opposite direction and then route cha

lagg(4): Add support for allocating TLS receive tags.

The TLS receive tags are allocated directly from the receiving interface,
because mbufs are flowing in the opposite direction and then route change
checks are not useful, because they only work for outgoing traffic.

Differential revision: https://reviews.freebsd.org/D32356
Sponsored by: NVIDIA Networking

show more ...