#
07b16b1e |
| 03-Sep-2024 |
Zhenlei Huang <zlei@FreeBSD.org> |
if_vlan: Stop checking for failures from malloc(M_WAITOK)
Fixes: b08d611de835 fix vlan locking to permit sx acquisition in ioctl calls MFC after: 1 week Differential Revision: https://reviews.freebs
if_vlan: Stop checking for failures from malloc(M_WAITOK)
Fixes: b08d611de835 fix vlan locking to permit sx acquisition in ioctl calls MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D45852
show more ...
|
#
828445cc |
| 21-Aug-2024 |
Konstantin Belousov <kib@FreeBSD.org> |
if_vlan: set if_cap{abilities2,enable2} after IFCAP_IPSEC_OFFLOAD is recalculated
This makes the vlan IPSEC offload really functional.
Noted by: Ariel Ehrenberg <aehrenberg@nvidia.com> Sponsored by
if_vlan: set if_cap{abilities2,enable2} after IFCAP_IPSEC_OFFLOAD is recalculated
This makes the vlan IPSEC offload really functional.
Noted by: Ariel Ehrenberg <aehrenberg@nvidia.com> Sponsored by: NVidia networking
show more ...
|
#
84abf7e2 |
| 17-Jul-2024 |
Konstantin Belousov <kib@FreeBSD.org> |
ipsec_offload: support vlans
Sponsored by: NVIDIA networking
|
#
4f4c34e9 |
| 14-Aug-2024 |
Konstantin Belousov <kib@FreeBSD.org> |
if_vlan.c: remove stray include of sys/cdefs.h
Sponsored by: NVidia networking
|
#
aa386085 |
| 28-Jun-2024 |
Zhenlei Huang <zlei@FreeBSD.org> |
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 ...
|
Revision tags: release/14.1.0 |
|
#
bdd12889 |
| 21-May-2024 |
Kristof Provost <kp@FreeBSD.org> |
if_vlan: handle VID conflicts
If we fail to change the vlan id we have to undo the removal (and vlan id change) in the error path. Otherwise we'll have removed the vlan object from the hash table, a
if_vlan: handle VID conflicts
If we fail to change the vlan id we have to undo the removal (and vlan id change) in the error path. Otherwise we'll have removed the vlan object from the hash table, and have the wrong vlan id as well. Subsequent modification attempts will then try to remove an entry which doesn't exist, and panic.
Undo the vlan id modification if the insertion in the hash table fails, and re-insert it under the original vlan id.
PR: 279195 Reviewed by: zlei MFC atfer: 1 week Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D45285
show more ...
|
Revision tags: release/13.3.0, release/14.0.0 |
|
#
ab393e95 |
| 12-Oct-2023 |
Kristof Provost <kp@FreeBSD.org> |
netlink: move NETLINK define to opt_global.h
Move the NETLINK define into opt_global.h so we can rely on it being set correctly, without having to remember to include opt_netlink.h. This ensures tha
netlink: move NETLINK define to opt_global.h
Move the NETLINK define into opt_global.h so we can rely on it being set correctly, without having to remember to include opt_netlink.h. This ensures that the NETLINK define is correctly set. If not we may end up with unloadable modules, due to missing symbols (such as nlmsg_get_group_writer).
PR: 274306 Reviewed by: imp, markj MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D42179
show more ...
|
#
b451dcc8 |
| 05-Sep-2023 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
if_vlan: Always default to 802.1q.
There is no reason for this fallback to be conditional on COMPAT_FREEBSD12.
PR: 273539 MFC after: 1 week Sponsored by: Klara, Inc. Sponsored by: NetApp, Inc. Rev
if_vlan: Always default to 802.1q.
There is no reason for this fallback to be conditional on COMPAT_FREEBSD12.
PR: 273539 MFC after: 1 week Sponsored by: Klara, Inc. Sponsored by: NetApp, Inc. Reviewed by: melifaro, allanjude Differential Revision: https://reviews.freebsd.org/D41717
show more ...
|
#
685dc743 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
b1a39c31 |
| 12-Aug-2023 |
Kevin Bowling <kbowling@FreeBSD.org> |
vlan: Respect IFCAP_LRO mask
vlan_capabilities(), used by the IFCAP ioctl, was not respecting the IFCAP_LRO bit if it was masked by the requestor.
This prevented if_bridge(4) from automasking LRO w
vlan: Respect IFCAP_LRO mask
vlan_capabilities(), used by the IFCAP ioctl, was not respecting the IFCAP_LRO bit if it was masked by the requestor.
This prevented if_bridge(4) from automasking LRO with a message like: bridge0: can't disable some capabilities on em3.11: 0x400
This also prevented manually disabling LRO from any vlan interface.
PR: 254596 Reported by: Paul Vixie <paul@redbarn.org> MFC after: 1 week
show more ...
|
#
fb69ed39 |
| 12-Aug-2023 |
Kristof Provost <kp@FreeBSD.org> |
Revert "if_vlan: do not enable LRO for bridge interaces"
This reverts commit 5f11a33ceeb385477cb22d9ad5941061c5a26be9.
As requested by Kevin Bowling. He explains:
> The subtle bug was that vlan_ca
Revert "if_vlan: do not enable LRO for bridge interaces"
This reverts commit 5f11a33ceeb385477cb22d9ad5941061c5a26be9.
As requested by Kevin Bowling. He explains:
> The subtle bug was that vlan_capabilities() in if_vlan was not obeying > the requested mask from its IFCAP ioctl.
show more ...
|
#
5f11a33c |
| 11-Aug-2023 |
Paul Vixie <paul@redbarn.org> |
if_vlan: do not enable LRO for bridge interaces
If the parent interface is not a bridge and can do LRO and checksum offloading on VLANs, then guess it may do LRO on VLANs. False positive here cost n
if_vlan: do not enable LRO for bridge interaces
If the parent interface is not a bridge and can do LRO and checksum offloading on VLANs, then guess it may do LRO on VLANs. False positive here cost nothing, while false negative may lead to some confusions. According to Wikipedia:
"LRO should not operate on machines acting as routers, as it breaks the end-to-end principle and can significantly impact performance."
The same reasoning applies to machines acting as bridges.
PR: 254596 MFC after: 3 weeks
show more ...
|
#
92c23f6d |
| 12-May-2023 |
Kristof Provost <kp@FreeBSD.org> |
vlan: fix setting flags on a QinQ interface
Setting vlan flags needlessly takes the exclusive VLAN_XLOCK().
If we have stacked vlan devices (i.e. QinQ) and we set vlan flags (e.g. IFF_PROMISC) we c
vlan: fix setting flags on a QinQ interface
Setting vlan flags needlessly takes the exclusive VLAN_XLOCK().
If we have stacked vlan devices (i.e. QinQ) and we set vlan flags (e.g. IFF_PROMISC) we call rtnl_handle_ifevent() to send a notification about the interface. This ends up calling SIOCGIFMEDIA, which requires the VLAN_SLOCK(). Trying to take that one with the VLAN_XLOCK() held deadlocks us.
There's no need for the exclusive lock though, as we're only accessing parent/trunk information, not modifying it, so a shared lock is sufficient.
While here also add a test case for this issue.
Backtrace: shared lock of (sx) vlan_sx @ /usr/src/sys/net/if_vlan.c:2192 while exclusively locked from /usr/src/sys/net/if_vlan.c:2307 panic: excl->share cpuid = 29 time = 1683873033 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe015d4ad4b0 vpanic() at vpanic+0x152/frame 0xfffffe015d4ad500 panic() at panic+0x43/frame 0xfffffe015d4ad560 witness_checkorder() at witness_checkorder+0xcb5/frame 0xfffffe015d4ad720 _sx_slock_int() at _sx_slock_int+0x67/frame 0xfffffe015d4ad760 vlan_ioctl() at vlan_ioctl+0xf8/frame 0xfffffe015d4ad7c0 dump_iface() at dump_iface+0x12f/frame 0xfffffe015d4ad840 rtnl_handle_ifevent() at rtnl_handle_ifevent+0xab/frame 0xfffffe015d4ad8c0 if_setflag() at if_setflag+0xf6/frame 0xfffffe015d4ad930 ifpromisc() at ifpromisc+0x2a/frame 0xfffffe015d4ad960 vlan_setflags() at vlan_setflags+0x60/frame 0xfffffe015d4ad990 vlan_ioctl() at vlan_ioctl+0x216/frame 0xfffffe015d4ad9f0 if_setflag() at if_setflag+0xe4/frame 0xfffffe015d4ada60 ifpromisc() at ifpromisc+0x2a/frame 0xfffffe015d4ada90 bridge_ioctl_add() at bridge_ioctl_add+0x499/frame 0xfffffe015d4adb10 bridge_ioctl() at bridge_ioctl+0x328/frame 0xfffffe015d4adbc0 ifioctl() at ifioctl+0x972/frame 0xfffffe015d4adcc0 kern_ioctl() at kern_ioctl+0x1fe/frame 0xfffffe015d4add30 sys_ioctl() at sys_ioctl+0x154/frame 0xfffffe015d4ade00 amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe015d4adf30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe015d4adf30 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x22b0f0ef8d8a, rsp = 0x22b0ec63f2c8, rbp = 0x22b0ec63f380 --- KDB: enter: panic [ thread pid 5715 tid 101132 ]
Sponsored by: Rubicon Communications, LLC ("Netgate")
show more ...
|
#
089104e0 |
| 19-Apr-2023 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
netlink: add netlink interfaces to if_clone
This change adds netlink create/modify/dump interfaces to the `if_clone.c`. The previous attempt with storing the logic inside `netlink/route/iface_driver
netlink: add netlink interfaces to if_clone
This change adds netlink create/modify/dump interfaces to the `if_clone.c`. The previous attempt with storing the logic inside `netlink/route/iface_drivers.c` did not quite work, as, for example, dumping interface-specific state (like vlan id or vlan parent) required some peeking into the private interfaces.
The new interfaces are added in a compatible way - callers don't have to do anything unless they are extended with Netlink.
Reviewed by: kp Differential Revision: https://reviews.freebsd.org/D39032 MFC after: 1 month
show more ...
|
Revision tags: release/13.2.0 |
|
#
66bdbcd5 |
| 03-Mar-2023 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
net: unify mtu update code
Subscribers: imp, ae, glebius
Differential Revision: https://reviews.freebsd.org/D38893
|
#
c255d1a4 |
| 23-Jan-2023 |
Justin Hibbits <jhibbits@FreeBSD.org> |
IfAPI: Add if_llsoftc member accessors for TOEDEV
Summary: Keep TOEDEV() macro for backwards compatibility, and add a SETTOEDEV() macro to complement with the new accessors.
Sponsored by: Juniper N
IfAPI: Add if_llsoftc member accessors for TOEDEV
Summary: Keep TOEDEV() macro for backwards compatibility, and add a SETTOEDEV() macro to complement with the new accessors.
Sponsored by: Juniper Networks, Inc. Reviewed by: glebius Differential Revision: https://reviews.freebsd.org/D38199
show more ...
|
#
2c2b37ad |
| 13-Jan-2023 |
Justin Hibbits <jhibbits@FreeBSD.org> |
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 ...
|
Revision tags: release/12.4.0 |
|
#
91ebcbe0 |
| 22-Sep-2022 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
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 ...
|
#
151abc80 |
| 22-Jul-2022 |
Kristof Provost <kp@FreeBSD.org> |
if_vlan: avoid hash table thrashing when adding and removing entries
vlan_remhash() uses incorrect value for b.
When using the default value for VLAN_DEF_HWIDTH (4), the VLAN hash-list table expand
if_vlan: avoid hash table thrashing when adding and removing entries
vlan_remhash() uses incorrect value for b.
When using the default value for VLAN_DEF_HWIDTH (4), the VLAN hash-list table expands from 16 chains to 32 chains as the 129th entry is added. trunk->hwidth becomes 5. Say a few more entries are added and there are now 135 entries. trunk-hwidth will still be 5. If an entry is removed, vlan_remhash() will calculate a value of 32 for b. refcnt will be decremented to 134. The if comparison at line 473 will return true and vlan_growhash() will be called. The VLAN hash-list table will be compressed from 32 chains wide to 16 chains wide. hwidth will become 4. This is an error, and it can be seen when a new VLAN is added. The table will again be expanded. If an entry is then removed, again the table is contracted.
If the number of VLANS stays in the range of 128-512, each time an insert follows a remove, the table will expand. Each time a remove follows an insert, the table will be contracted.
The fix is simple. The line 473 should test that the number of entries has decreased such that the table should be contracted using what would be the new value of hwidth. line 467 should be:
b = 1 << (trunk->hwidth - 1);
PR: 265382 Reviewed by: kp MFC after: 2 weeks Sponsored by: NetApp, Inc.
show more ...
|
#
663f556b |
| 19-Jul-2022 |
Kristof Provost <kp@FreeBSD.org> |
if_vlan: allow vlan and vlanproto to be changed
It's currently not possible to change the vlan ID or vlan protocol (i.e. 802.1q vs. 802.1ad) without de-configuring the interface (i.e. ifconfig vlanX
if_vlan: allow vlan and vlanproto to be changed
It's currently not possible to change the vlan ID or vlan protocol (i.e. 802.1q vs. 802.1ad) without de-configuring the interface (i.e. ifconfig vlanX -vlandev). Add a specific flow for this, allowing both the protocol and id (but not parent interface) to be changed without going through the '-vlandev' step.
Reviewed by: glebius Sponsored by: Rubicon Communications, LLC ("Netgate") Differential Revision: https://reviews.freebsd.org/D35846
show more ...
|
#
892eded5 |
| 25-May-2022 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
vlan(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
vlan(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 ...
|
#
f2ab9160 |
| 19-May-2022 |
Andrey V. Elsukov <ae@FreeBSD.org> |
[vlan + lagg] add IFNET_EVENT_UPDATE_BAUDRATE event
use it to update if_baudrate for vlan interfaces created on the LACP lagg.
Differential revision: https://reviews.freebsd.org/D33405
|
Revision tags: release/13.1.0 |
|
#
2884a936 |
| 14-Apr-2022 |
John Baldwin <jhb@FreeBSD.org> |
vlan: ifa is only used under #ifdef INET.
|
#
78bc3d5e |
| 14-Feb-2022 |
Kristof Provost <kp@FreeBSD.org> |
vlan: allow net.link.vlan.mtag_pcp to be set per vnet
The primary reason for this change is to facilitate testing.
MFC after: 1 week
|
Revision tags: release/12.3.0 |
|
#
c782ea8b |
| 14-Sep-2021 |
John Baldwin <jhb@FreeBSD.org> |
Add a switch structure for send tags.
Move the type and function pointers for operations on existing send tags (modify, query, next, free) out of 'struct ifnet' and into a new 'struct if_snd_tag_sw'
Add a switch structure for send tags.
Move the type and function pointers for operations on existing send tags (modify, query, next, free) out of 'struct ifnet' and into a new 'struct if_snd_tag_sw'. A pointer to this structure is added to the generic part of send tags and is initialized by m_snd_tag_init() (which now accepts a switch structure as a new argument in place of the type).
Previously, device driver ifnet methods switched on the type to call type-specific functions. Now, those type-specific functions are saved in the switch structure and invoked directly. In addition, this more gracefully permits multiple implementations of the same tag within a driver. In particular, NIC TLS for future Chelsio adapters will use a different implementation than the existing NIC TLS support for T6 adapters.
Reviewed by: gallatin, hselasky, kib (older version) Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D31572
show more ...
|