History log of /freebsd/sys/net/if_vlan.c (Results 1 – 25 of 525)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12345678910>>...21