Revision tags: release/12.3.0 |
|
#
eb680a63 |
| 25-Aug-2021 |
Luiz Otavio O Souza <loos@FreeBSD.org> |
if_bridge: add ALTQ support
Similar to the recent addition of ALTQ support to if_vlan.
Reviewed by: donner Obtained from: pfsense MFC after: 1 week Sponsored by: Rubicon Communications, LLC ("Netga
if_bridge: add ALTQ support
Similar to the recent addition of ALTQ support to if_vlan.
Reviewed by: donner Obtained from: pfsense MFC after: 1 week Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D31675
show more ...
|
#
33306493 |
| 23-Jul-2021 |
Kristof Provost <kp@FreeBSD.org> |
if_bridge: allow MTU changes
if_bridge used to only allow MTU changes if the new MTU matched that of all member interfaces. This doesn't really make much sense, in that we really shouldn't be allowe
if_bridge: allow MTU changes
if_bridge used to only allow MTU changes if the new MTU matched that of all member interfaces. This doesn't really make much sense, in that we really shouldn't be allowed to change the MTU of bridge member in the first place.
Instead we now change the MTU of all member interfaces. If one fails we revert all interfaces back to the original MTU.
We do not address the issue where bridge member interface MTUs can be changed here.
Reviewed by: donner Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D31288
show more ...
|
Revision tags: release/13.0.0 |
|
#
38c09513 |
| 21-Feb-2021 |
Kristof Provost <kp@FreeBSD.org> |
bridge: Remove members when assigned to a new vnet
When the bridge is moved to a different vnet we must remove all of its member interfaces (and span interfaces), because we don't know if those will
bridge: Remove members when assigned to a new vnet
When the bridge is moved to a different vnet we must remove all of its member interfaces (and span interfaces), because we don't know if those will be moved along with it. We don't want to hold references to interfaces not in our vnet.
Reviewed by: donner@ MFC after: 1 week Sponsored by: Orange Business Services Differential Revision: https://reviews.freebsd.org/D28859
show more ...
|
#
89fa9c34 |
| 21-Feb-2021 |
Kristof Provost <kp@FreeBSD.org> |
bridge/stp: Ensure we enter NET_EPOCH whenever we can send traffic
Reviewed by: donner@ MFC after: 1 week Sponsored by: Orange Business Services Differential Revision: https://reviews.freebsd.org/D2
bridge/stp: Ensure we enter NET_EPOCH whenever we can send traffic
Reviewed by: donner@ MFC after: 1 week Sponsored by: Orange Business Services Differential Revision: https://reviews.freebsd.org/D28858
show more ...
|
Revision tags: release/12.2.0 |
|
#
4af1bd81 |
| 06-Oct-2020 |
Kristof Provost <kp@FreeBSD.org> |
bridge: call member interface ioctl() without NET_EPOCH
We're not allowed to hold NET_EPOCH while sleeping, so when we call ioctl() handlers for member interfaces we cannot be in NET_EPOCH. We stil
bridge: call member interface ioctl() without NET_EPOCH
We're not allowed to hold NET_EPOCH while sleeping, so when we call ioctl() handlers for member interfaces we cannot be in NET_EPOCH. We still need some protection of our CK_LISTs, so hold BRIDGE_LOCK instead.
That requires changing BRIDGE_LOCK into a sleepable lock, and separating the BRIDGE_RT_LOCK, to protect bridge_rtnode lists. That lock is taken in the data path (while in NET_EPOCH), so it cannot be a sleepable lock.
While here document the locking strategy.
MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D26418
show more ...
|
#
662c1305 |
| 01-Sep-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
net: clean up empty lines in .c and .h files
|
#
c7aa572c |
| 31-Jul-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
93ed6ade |
| 18-Jul-2020 |
Kristof Provost <kp@FreeBSD.org> |
bridge: Don't sleep during epoch
While it doesn't trigger INVARIANTS or WITNESS on head it does in stable/12. There's also no reason for it, as we can easily report the out of memory error to the ca
bridge: Don't sleep during epoch
While it doesn't trigger INVARIANTS or WITNESS on head it does in stable/12. There's also no reason for it, as we can easily report the out of memory error to the caller (i.e. userspace). All of these can already fail.
PR: 248046 MFC after: 3 days
show more ...
|
Revision tags: release/11.4.0 |
|
#
fffd27e5 |
| 26-Apr-2020 |
Kristof Provost <kp@FreeBSD.org> |
bridge: epoch-ification
Run the bridge datapath under epoch, rather than under the BRIDGE_LOCK().
We still take the BRIDGE_LOCK() whenever we insert or delete items in the relevant lists, but we us
bridge: epoch-ification
Run the bridge datapath under epoch, rather than under the BRIDGE_LOCK().
We still take the BRIDGE_LOCK() whenever we insert or delete items in the relevant lists, but we use epoch callbacks to free items so that it's safe to iterate the lists without the BRIDGE_LOCK.
Tests on mercat5/6 shows this increases bridge throughput significantly, from 3.7Mpps to 18.6Mpps.
Reviewed by: emaste, philip, melifaro MFC after: 2 months Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D24250
show more ...
|
#
fac24ad7 |
| 18-Apr-2020 |
Kristof Provost <kp@FreeBSD.org> |
bridge: Simplify mac address generation
Unconditionally use ether_gen_addr() to generate bridge mac addresses. This function is now less likely to generate duplicate mac addresses across jails. The
bridge: Simplify mac address generation
Unconditionally use ether_gen_addr() to generate bridge mac addresses. This function is now less likely to generate duplicate mac addresses across jails. The old hand rolled hostid based code adds no value.
Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D24432
show more ...
|
#
ae4b6259 |
| 17-Apr-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Unbreak build by reverting if_bridge part of r360047.
Pointy hat to: melifaro
|
#
67452942 |
| 17-Apr-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Finish r191148: replace rtentry with route in if_bridge if_output() callback.
Generic if_output() callback signature was modified to use struct route instead of struct rtentry in r191148, back in 2
Finish r191148: replace rtentry with route in if_bridge if_output() callback.
Generic if_output() callback signature was modified to use struct route instead of struct rtentry in r191148, back in 2009.
Quoting commit message:
Change if_output to take a struct route as its fourth argument in order to allow passing a cached struct llentry * down to L2
Fix bridge_output() to match this signature and update the remaining comment in if_var.h.
Reviewed by: kp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24394
show more ...
|
#
dd00a42a |
| 05-Apr-2020 |
Kristof Provost <kp@FreeBSD.org> |
bridge: Change lists to CK_LIST as a peparation for epochification
Prepare the ground for a rework of the bridge locking approach. We will use an epoch-based approach in the datapath and making it s
bridge: Change lists to CK_LIST as a peparation for epochification
Prepare the ground for a rework of the bridge locking approach. We will use an epoch-based approach in the datapath and making it safe to iterate over the interface, span and rtnode lists without holding the BRIDGE_LOCK. Replace the relevant lists by their ConcurrencyKit equivalents.
No functional change in this commit.
Reviewed by: emaste, ae, philip (previous version) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D24249
show more ...
|
#
75dfc66c |
| 27-Feb-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r358269 through r358399.
|
#
7029da5c |
| 26-Feb-2020 |
Pawel Biernacki <kaktus@FreeBSD.org> |
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly mark
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT
Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718
show more ...
|
#
33b1fe11 |
| 26-Feb-2020 |
Kristof Provost <kp@FreeBSD.org> |
bridge: Move locking defines into if_bridge.c
The locking defines for if_bridge used to live in if_bridgevar.h, but they're only ever used by the bridge implementation itself (in if_bridge.c). Movin
bridge: Move locking defines into if_bridge.c
The locking defines for if_bridge used to live in if_bridgevar.h, but they're only ever used by the bridge implementation itself (in if_bridge.c). Moving them into the .c file.
Reported by: philip, emaste Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D23808
show more ...
|
#
051669e8 |
| 25-Jan-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r356931 through r357118.
|
#
84becee1 |
| 22-Jan-2020 |
Alexander Motin <mav@FreeBSD.org> |
Update route MTUs for bridge, lagg and vlan interfaces.
Those interfaces may implicitly change their MTU on addition of parent interface in addition to normal SIOCSIFMTU ioctl path, where the route
Update route MTUs for bridge, lagg and vlan interfaces.
Those interfaces may implicitly change their MTU on addition of parent interface in addition to normal SIOCSIFMTU ioctl path, where the route MTUs are updated normally.
MFC after: 2 weeks Sponsored by: iXsystems, Inc.
show more ...
|
#
8d5c56da |
| 01-Jan-2020 |
Gleb Smirnoff <glebius@FreeBSD.org> |
In r343631 error code for a packet blocked by a firewall was changed from EACCES to EPERM. This change was not intentional, so fix that. Return EACCESS if a firewall forbids sending.
Noticed by: ae
|
Revision tags: release/12.1.0, release/11.3.0 |
|
#
0269ae4c |
| 06-Jun-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @348740
Sponsored by: The FreeBSD Foundation
|
#
d8b98543 |
| 29-May-2019 |
Kyle Evans <kevans@FreeBSD.org> |
if_bridge(4): Complete bpf auditing of local traffic over the bridge
There were two remaining "gaps" in auditing local bridge traffic with bpf(4):
Locally originated outbound traffic from a member
if_bridge(4): Complete bpf auditing of local traffic over the bridge
There were two remaining "gaps" in auditing local bridge traffic with bpf(4):
Locally originated outbound traffic from a member interface is invisible to the bridge's bpf(4) interface. Inbound traffic locally destined to a member interface is invisible to the member's bpf(4) interface -- this traffic has no chance after bridge_input to otherwise pass it over, and it wasn't originally received on this interface.
I call these "gaps" because they don't affect conventional bridge setups. Alas, being able to establish an audit trail of all locally destined traffic for setups that can function like this is useful in some scenarios.
Reviewed by: kp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D19757
show more ...
|
#
7648bc9f |
| 13-May-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @347527
Sponsored by: The FreeBSD Foundation
|
#
3c3aa8c1 |
| 17-Apr-2019 |
Kyle Evans <kevans@FreeBSD.org> |
net: adjust randomized address bits
Give devices that need a MAC a 16-bit allocation out of the FreeBSD Foundation OUI range. Change the name ether_fakeaddr to ether_gen_addr now that we're dealing
net: adjust randomized address bits
Give devices that need a MAC a 16-bit allocation out of the FreeBSD Foundation OUI range. Change the name ether_fakeaddr to ether_gen_addr now that we're dealing real MAC addresses with a real OUI rather than random locally-administered addresses.
Reviewed by: bz, rgrimes Differential Revision: https://reviews.freebsd.org/D19587
show more ...
|
#
415e34c4 |
| 29-Mar-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead@r345677
|
#
93c9d319 |
| 28-Mar-2019 |
Kyle Evans <kevans@FreeBSD.org> |
if_bridge(4): ensure all traffic passing over the bridge is accounted for
Consider a bridge0 with em0 and em1 members. Traffic rx'd by em0 and transmitted by bridge0 through em1 gets accounted for i
if_bridge(4): ensure all traffic passing over the bridge is accounted for
Consider a bridge0 with em0 and em1 members. Traffic rx'd by em0 and transmitted by bridge0 through em1 gets accounted for in IPACKETS/IBYTES and bridge0 bpf -- assuming it's not unicast traffic destined for em1. Unicast traffic destined for em1 traffic is not accounted for by any mechanism, and isn't pushed through bridge0's bpf machinery as any other packets that pass over the bridge do.
Fix this and simplify GRAB_OUR_PACKETS by bailing out early if it was rx'd by the interface that it was addressed for. Everything else there is relevant for any traffic that came in from one member that's being directed at another member of the bridge.
Reviewed by: kp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D19614
show more ...
|