Re: [PATCH net] vlan: fix skb_under_panic() and races when toggling HW VLAN offload

On Mon, 20 Jul 2026 07:26:22 +0000 Eric Dumazet wrote:

Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or
NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(),
which dynamically changes vlandev->hard_header_len.

This causes two issues:
1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2)
   read dev->hard_header_len without holding RTNL lock. Mutating
   hard_header_len dynamically under RTNL creates a data race where upper
   layers reserve insufficient headroom based on a stale hard_header_len,
   resulting in skb_under_panic when vlan_dev_hard_header() is called.
2. In addition, vlan_transfer_features() updated hard_header_len without
   updating header_ops, causing a mismatch between allocated headroom
   and header creation.

A VLAN interface may require software VLAN header insertion at any point
(e.g., if reorder_hdr is disabled or HW offload is unavailable). Always
setting hard_header_len = real_dev->hard_header_len + VLAN_HLEN and using
vlan_header_ops unconditionally ensures sufficient headroom is reserved
by all upper layers and avoids any data race on hard_header_len during ETHTOOL
feature changes.

Hi Eric,

Looks like this broke VXLAN tests:

https://netdev-ctrl.bots.linux.dev/logview.html?f=/logs/vmksft/net/results/742304/2-test-vxlan-mdb-sh/stdout

AI bot says:

The NIPA CI detected a regression introduced by this patch in the VXLAN
MDB selftest (tools/testing/selftests/net/test_vxlan_mdb.sh).

All data path forwarding sub-tests fail on both normal and debug kernel
builds, while the control path (MDB entry add/replace/delete) tests
continue to pass. The failure is 100% reproducible across both runs.

The test topology uses VLAN subinterfaces (br0.10, br0.20) on a bridge
that has a VXLAN device as a member. mausezahn injects multicast frames
from the VLAN subinterface and tc ingress filters on the peer namespace
count packet arrivals to verify forwarding.

With this patch, `vlan_passthru_header_ops` has been removed and all
VLAN devices now unconditionally use `vlan_header_ops`, which calls
`vlan_dev_hard_header()` and inserts an 802.1Q VLAN header in software.
Previously, when the underlying device had `NETIF_F_HW_VLAN_CTAG_TX`
set (as veth does), the passthrough header ops were used and no software
VLAN tag was inserted.

This change causes frames injected from VLAN subinterfaces in the test
to arrive at the peer with an unexpected software-inserted VLAN tag,
breaking the tc filter matches used to verify delivery. Tests that check
frames are *dropped* still pass (the frames never arrive regardless),
but tests that check frames are *forwarded* all fail.

Failing test output excerpt:
  TEST: Destination IP - match                                        [FAIL]
  TEST: Destination IP - no match                                     [FAIL]
  TEST: Forward valid source - first VTEP                             [FAIL]
  TEST: Forward valid source - second VTEP                            [FAIL]
  ...

The pattern holds for all four overlay/underlay combinations (IPv4/IPv6
× IPv4/IPv6).

Could you please take a look? It seems the unconditional software VLAN
insertion breaks the VXLAN MDB data path when veth (or similarly capable)
devices are used as the underlay.