History log of /freebsd/sys/net/if_bridge.c (Results 26 – 50 of 497)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12345678910>>...20