#
2aaf9152 |
| 18-Mar-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead@r345275
|
#
4920f9a3 |
| 15-Mar-2019 |
Kyle Evans <kevans@FreeBSD.org> |
if_bridge(4): Drop pointless rtflush
At this point, all routes should've already been dropped by removing all members from the bridge. This condition is in-fact KASSERT'd in the line immediately abo
if_bridge(4): Drop pointless rtflush
At this point, all routes should've already been dropped by removing all members from the bridge. This condition is in-fact KASSERT'd in the line immediately above where this nop flush was added.
show more ...
|
#
6e6b93fe |
| 15-Mar-2019 |
Kyle Evans <kevans@FreeBSD.org> |
Revert r345192: Too many trees in play for bridge(4) bits
An accidental appendage was committed that has not undergone review yet.
|
#
4b4b284d |
| 15-Mar-2019 |
Kyle Evans <kevans@FreeBSD.org> |
if_bridge(4): Drop pointless rtflush
At this point, all routes should've already been dropped by removing all members from the bridge. This condition is in-fact KASSERT'd in the line immediately abo
if_bridge(4): Drop pointless rtflush
At this point, all routes should've already been dropped by removing all members from the bridge. This condition is in-fact KASSERT'd in the line immediately above where this nop flush was added.
show more ...
|
#
43d3127c |
| 15-Mar-2019 |
Kristof Provost <kp@FreeBSD.org> |
bridge: Fix STP-related panic
After r345180 we need to have the appropriate vnet context set to delete an rtnode in bridge_rtnode_destroy(). That's usually the case, but not when it's called by the
bridge: Fix STP-related panic
After r345180 we need to have the appropriate vnet context set to delete an rtnode in bridge_rtnode_destroy(). That's usually the case, but not when it's called by the STP code (through bstp_notify_rtage()).
We have to set the vnet context in bridge_rtable_expire() just as we do in the other STP callback bridge_state_change().
Reviewed by: kevans
show more ...
|
#
a87407ff |
| 15-Mar-2019 |
Kyle Evans <kevans@FreeBSD.org> |
if_bridge(4): Fix module teardown
bridge_rtnode_zone still has outstanding allocations at the time of destruction in the current model because all of the interface teardown happens in a VNET_SYSUNIN
if_bridge(4): Fix module teardown
bridge_rtnode_zone still has outstanding allocations at the time of destruction in the current model because all of the interface teardown happens in a VNET_SYSUNINIT, -after- the MOD_UNLOAD has already been processed. The SYSUNINIT triggers destruction of the interfaces, which then attempts to free the memory from the zone that's already been destroyed, and we hit a panic.
Solve this by virtualizing the uma_zone we allocate the rtnodes from to fix the ordering. bridge_rtable_fini should also take care to flush any remaining routes that weren't taken care of when dynamic routes were flushed in bridge_stop.
Reviewed by: kp Differential Revision: https://reviews.freebsd.org/D19578
show more ...
|
#
6b7e0c1c |
| 14-Mar-2019 |
Kyle Evans <kevans@FreeBSD.org> |
ether: centralize fake hwaddr generation
We currently have two places with identical fake hwaddr generation -- if_vxlan and if_bridge. Lift it into if_ethersubr for reuse in other interfaces that ma
ether: centralize fake hwaddr generation
We currently have two places with identical fake hwaddr generation -- if_vxlan and if_bridge. Lift it into if_ethersubr for reuse in other interfaces that may also need a fake addr.
Reviewed by: bryanv, kp, philip Differential Revision: https://reviews.freebsd.org/D19573
show more ...
|
#
b18a4cca |
| 05-Mar-2019 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r344786
|
#
c3c93809 |
| 04-Mar-2019 |
Alexander Motin <mav@FreeBSD.org> |
bridge: Fix spurious warnings about capabilities
Mask off the bits we don't care about when checking that capabilities of the member interfaces have been disabled as intended.
Submitted by: Ryan Mo
bridge: Fix spurious warnings about capabilities
Mask off the bits we don't care about when checking that capabilities of the member interfaces have been disabled as intended.
Submitted by: Ryan Moeller <ryan@ixsystems.com> Reviewed by: kristof, mav MFC after: 1 week Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D18924
show more ...
|
#
c2c227a5 |
| 03-Feb-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r343571 through r343711.
|
#
b252313f |
| 01-Feb-2019 |
Gleb Smirnoff <glebius@FreeBSD.org> |
New pfil(9) KPI together with newborn pfil API and control utility.
The KPI have been reviewed and cleansed of features that were planned back 20 years ago and never implemented. The pfil(9) intern
New pfil(9) KPI together with newborn pfil API and control utility.
The KPI have been reviewed and cleansed of features that were planned back 20 years ago and never implemented. The pfil(9) internals have been made opaque to protocols with only returned types and function declarations exposed. The KPI is made more strict, but at the same time more extensible, as kernel uses same command structures that userland ioctl uses.
In nutshell [KA]PI is about declaring filtering points, declaring filters and linking and unlinking them together.
New [KA]PI makes it possible to reconfigure pfil(9) configuration: change order of hooks, rehook filter from one filtering point to a different one, disconnect a hook on output leaving it on input only, prepend/append a filter to existing list of filters.
Now it possible for a single packet filter to provide multiple rulesets that may be linked to different points. Think of per-interface ACLs in Cisco or Juniper. None of existing packet filters yet support that, however limited usage is already possible, e.g. default ruleset can be moved to single interface, as soon as interface would pride their filtering points.
Another future feature is possiblity to create pfil heads, that provide not an mbuf pointer but just a memory pointer with length. That would allow filtering at very early stages of a packet lifecycle, e.g. when packet has just been received by a NIC and no mbuf was yet allocated.
Differential Revision: https://reviews.freebsd.org/D18951
show more ...
|
Revision tags: release/12.0.0 |
|
#
14b841d4 |
| 11-Aug-2018 |
Kyle Evans <kevans@FreeBSD.org> |
MFH @ r337607, in preparation for boarding
|
#
5f901c92 |
| 24-Jul-2018 |
Andrew Turner <andrew@FreeBSD.org> |
Use the new VNET_DEFINE_STATIC macro when we are defining static VNET variables.
Reviewed by: bz Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D16147
|
Revision tags: release/11.2.0 |
|
#
5c30b378 |
| 11-May-2018 |
Matt Macy <mmacy@FreeBSD.org> |
Allow different bridge types to coexist
if_bridge has a lot of limitations that make it scale poorly to higher data rates. In my projects/VPC branch I leverage the bridge interface between layers fo
Allow different bridge types to coexist
if_bridge has a lot of limitations that make it scale poorly to higher data rates. In my projects/VPC branch I leverage the bridge interface between layers for my high speed soft switch as well as for purposes of stacking in general.
Reviewed by: sbruno@ Approved by: sbruno@ Differential Revision: https://reviews.freebsd.org/D15344
show more ...
|
#
0437c8e3 |
| 11-Apr-2018 |
Brooks Davis <brooks@FreeBSD.org> |
Remove support for FDDI networks.
Defines in net/if_media.h remain in case code copied from ifconfig is in use elsewere (supporting non-existant media type is harmless).
Reviewed by: kib, jhb Spons
Remove support for FDDI networks.
Defines in net/if_media.h remain in case code copied from ifconfig is in use elsewere (supporting non-existant media type is harmless).
Reviewed by: kib, jhb Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D15017
show more ...
|
#
effaab88 |
| 23-Mar-2018 |
Kristof Provost <kp@FreeBSD.org> |
netpfil: Introduce PFIL_FWD flag
Forwarded packets passed through PFIL_OUT, which made it difficult for firewalls to figure out if they were forwarding or producing packets. This in turn is an issue
netpfil: Introduce PFIL_FWD flag
Forwarded packets passed through PFIL_OUT, which made it difficult for firewalls to figure out if they were forwarding or producing packets. This in turn is an issue for pf for IPv6 fragment handling: it needs to call ip6_output() or ip6_forward() to handle the fragments. Figuring out which was difficult (and until now, incorrect). Having pfil distinguish the two removes an ugly piece of code from pf.
Introduce a new variant of the netpfil callbacks with a flags variable, which has PFIL_FWD set for forwarded packets. This allows pf to reliably work out if a packet is forwarded.
Reviewed by: ae, kevans Differential Revision: https://reviews.freebsd.org/D13715
show more ...
|
#
fe267a55 |
| 27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys: general adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error pro
sys: general adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
No functional change intended.
show more ...
|
#
c2c014f2 |
| 07-Nov-2017 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Merge ^/head r323559 through r325504.
|
Revision tags: release/10.4.0 |
|
#
e5d34ca9 |
| 23-Sep-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r320180
|
#
ed9de14d |
| 21-Sep-2017 |
Kristof Provost <kp@FreeBSD.org> |
bridge: Set module version
This ensures that the loader will not load the module if it's also built in to the kernel.
PR: 220860 Submitted by: Eugene Grosbein <eugen@freebsd.org> Reported by: Mari
bridge: Set module version
This ensures that the loader will not load the module if it's also built in to the kernel.
PR: 220860 Submitted by: Eugene Grosbein <eugen@freebsd.org> Reported by: Marie Helene Kvello-Aune <marieheleneka@gmail.com>
show more ...
|
Revision tags: release/11.1.0 |
|
#
be27b311 |
| 04-May-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r317503 through r317807.
|
#
ebe42881 |
| 29-Apr-2017 |
Alexander Motin <mav@FreeBSD.org> |
Make if_bridge complain if it can't disable some capabilities.
MFC after: 2 weeks Sponsored by: iXsystems, Inc.
|
#
9b3ece1c |
| 04-Feb-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r313243
|
#
14f850f3 |
| 27-Jan-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r312720 through r312893.
|
#
ab5cda71 |
| 25-Jan-2017 |
Kristof Provost <kp@FreeBSD.org> |
bridge: Release the bridge lock when calling bridge_set_ifcap()
This calls ioctl() handlers for the different interfaces in the bridge. These handlers expect to get called in an ioctl context where
bridge: Release the bridge lock when calling bridge_set_ifcap()
This calls ioctl() handlers for the different interfaces in the bridge. These handlers expect to get called in an ioctl context where it's safe for them to sleep. We may not sleep with the bridge lock held.
However, we still need to protect the interface list, to ensure it doesn't get changed while we iterate over it. Use BRIDGE_XLOCK(), which prevents bridge members from being removed. Adding bridge members is safe, because it uses LIST_INSERT_HEAD().
This caused panics when adding xen interfaces to a bridge.
PR: 216304 Reviewed by: ae MFC after: 1 week Sponsored by: RootBSD Differential Revision: https://reviews.freebsd.org/D9290
show more ...
|