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

On Thu, Jul 23, 2026 at 6:22 PM Jakub Kicinski [off-list ref] wrote:

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.

Ah right, we probably want to keep hard_header_len as is, and instead
inflate needed_headroom by 4 bytes.

ie in vlan_transfer_features() have somethng like:


        netif_inherit_tso_max(vlandev, dev);

-       if (vlan_hw_offload_capable(dev->features, vlan->vlan_proto))
-               vlandev->hard_header_len = dev->hard_header_len;
-       else
-               vlandev->hard_header_len = dev->hard_header_len + VLAN_HLEN;
+       vlandev->needed_headroom = dev->needed_headroom + VLAN_HLEN;
+       vlandev->hard_header_len = dev->hard_header_len;

Thanks!