[BUG] vlan: skb_under_panic when toggling NETIF_F_HW_VLAN_CTAG_TX on lower device

[xietangxin <xietangxin@h-partners.com>]

[BUG] vlan: skb_under_panic when toggling NETIF_F_HW_VLAN_CTAG_TX on lower device

Hi all,

We encountered a skb_under_panic triggered by toggling
NETIF_F_HW_VLAN_CTAG_TX on the lower device while a VLAN device is
up and sending traffic.

Call trace
==========

 skbuff: skb_under_panic: text:ffffc0d2900283d8 len:74 put:14
  head:ffff334820249c00 data:ffff334820249bfe tail:0x48 end:0xc0 dev:vlan4
 ------------[ cut here ]------------
 kernel BUG at net/core/skbuff.c:116!
 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
 Call trace:
  skb_panic+0xcc/0xd0
  __skb_checksum+0x0/0x480
  eth_header+0x48/0x1a0
  vlan_dev_hard_header+0xd0/0x284
  neigh_connected_output+0x16c/0x20c
  ip6_finish_output2+0x4b4/0xd74
  __ip6_finish_output.part.0+0x1ac/0x3b0
  ip6_finish_output+0x160/0x200
  ip6_output+0x13c/0x294
  ndisc_send_skb+0x41c/0x6f0
  ndisc_send_rs+0xac/0x3b0
  addrconf_rs_timer+0x42c/0x660
  call_timer_fn+0x54/0x290
  expire_timers+0x26c/0x420

Reproducer
==========

 # Create veth pair (NETIF_F_HW_VLAN_CTAG_TX is ON by default)
 ip link add veth0 type veth peer name veth1
 ip link set veth0 up
 ip link set veth1 up

 # Turn off HW VLAN TX offload on lower device
 ethtool -K veth0 tx-vlan-hw-insert off

 # Create VLAN device on veth0
 # At this point: header_ops = &vlan_header_ops, hard_header_len = 18
 ip link add link veth0 name veth0.10 type vlan id 10 reorder_hdr off
 ip addr add 192.168.10.1/24 dev veth0.10
 ip link set veth0.10 up

 # Turn HW VLAN TX offload back ON on lower device
 # This triggers NETDEV_FEAT_CHANGE -> vlan_transfer_features()
 # hard_header_len changes from 18 to 14, but header_ops is NOT updated
 ethtool -K veth0 tx-vlan-hw-insert on

 # When a packet is sent through veth0.10
 # - skb is allocated based on hard_header_len=14 -> ~16 bytes
 # - vlan_dev_hard_header() pushes VLAN_HLEN(4) + ETH_HLEN(14) = 18 bytes
 # - skb_under_panic!


Any feedback or guidance would be greatly appreciated.

-- 
Best regards,
Tangxin Xie