From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5D9093002DF for ; Thu, 29 Jan 2026 11:08:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769684891; cv=none; b=Qb/hEFGdEceP3v9YXkDCuxdJLLis4wSsnDGJkne/7Xi6LbYbdfI2oxzFpHn9YaIMhfJ4XctWKZVdqfcxQGEkJkyxgciMECMGOyPgC7wmO9a5r1I0gDyDw3CidQmBOyaBBksgz8Mf5XSR+LGK+bA2VKy8U999EtAfVD7CGXCFiLw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769684891; c=relaxed/simple; bh=ZpzWLfxWdzI35hED67bvl18C7frsG8QVBVGY1Td1kwQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HbBKbZDJ7gNnxYnirEc98cX1fH6Pcsu+Wx942gAlSYSPft+N7TelUDRyzatA5apq58zsV6+KvuVa1Nc1YMThoRd0EZRvYPVaNoSJpZWcqIXNRiEt1tS0V8c7ckEDO32ryO3RXHcpPWRnd83DDVKUuhCBngG3WlsBx6ibYJ1Bp+4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LqI6iBWO; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=ATYJxrXC; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LqI6iBWO"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="ATYJxrXC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769684889; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EjyeEr/0YxMv+W2aN9EYwTKNL4Eg3DNxiBTghibwjm0=; b=LqI6iBWOPrUp5eqMQ+LAZs6jpvzykNBEWc0fpl7f4Do7gGmrCJFunLZvxdNeKknl04br9J xYuWNyitlH9IG84vxpsshRQQ+m4+nwt79H411uomcRSEzBEA3JXrKoB0pbFtFshOnH51Zl /O7qIPWv2KS1MCXxeWFMtmJwtMFBLIg= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-441-wgGFSBGFM3qYyHDtWiW1gQ-1; Thu, 29 Jan 2026 06:08:08 -0500 X-MC-Unique: wgGFSBGFM3qYyHDtWiW1gQ-1 X-Mimecast-MFC-AGG-ID: wgGFSBGFM3qYyHDtWiW1gQ_1769684887 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-43591aacca2so666163f8f.1 for ; Thu, 29 Jan 2026 03:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769684887; x=1770289687; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=EjyeEr/0YxMv+W2aN9EYwTKNL4Eg3DNxiBTghibwjm0=; b=ATYJxrXCJz8Y4aChUZmeIMgiXonOkJfa52AsnUpZwTavfhIUUeOFx3wPpPLbdu1JWg m6uFzWR9UmnBH+BuwOCX3XMse7OBrlgPtXWj8CVH0QaIxSfe945k/csKoUyDBaCBf5RU NkPM8YOUECKEtwbpnFKhiRstipjZBRJ7DLz/mhBFnqfhunJQJ6aedJBC+FXNpSDNKk1o nfsE+mCGxn9xNObyv6/e6jPmbOFcC9SZCuxy9rRowPnY1SklVFY+EXgz5b7ZDrAQRDGG fic2r7C1nsoJW2WsD2Qs55QXNSeyZFRfelQ7jhBYgRsIw92kIZfaFVA+Q3cQPvBh7Mdg ZQqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769684887; x=1770289687; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EjyeEr/0YxMv+W2aN9EYwTKNL4Eg3DNxiBTghibwjm0=; b=vkXaLNjPI/WWlNHo/Q4SNH1/G8JgGtcSML2iGhPgo3TkgRGKb2tL+nGHjr9hkR6FFh 9cbnPywuASbfiOkr7WXiuLqCA4rQLTJhxu8726+0x8uRFvtyt37oeCO/dEbnYLvbpoO3 +J0KLoMBPS0Wgu11qnKkkMR+SbmDWby4fcACI/nqHP2FPV0/8zuCAHLOvXLxXZZAxgjD 5rQUgbSC1F7xgFIwy3YamVeD9v3pFrP5lnrweUcdA0YPuplvWfHtmIj218Kni8Kx4gjg RjDw/SjaG/Dighp4exD9o4LZWS/HZLf8MSzwbXGH2I9AHDG7YmVb97LElMcJTXu+92it sfNQ== X-Forwarded-Encrypted: i=1; AJvYcCUAUSskKK1cd/nkGYZDKvWgfJs9UeIp3Dy8Z2cPxKYzdFevKbQWGByiWp5Et8TUeJikrQnrqre+u6d1FDU=@vger.kernel.org X-Gm-Message-State: AOJu0YwECGO+YhobSwgzhatJBhIxYxomDad9wq7OcAyHpn2GgVgNOvn/ OoXrwlMHkJIJcniK3riQkbr7sGOYdqwPzEpKeFu+cRvMvGI25OpVlOGClojWlJgabw43b7tTHBv u9tGe0jvV9YtXgHpeulvsnpeJfHlPQ8iGttmVNWMsDmNG7MKotXRTPBH51Pg+Go0AXw== X-Gm-Gg: AZuq6aIrbEmMFJACON1HRABZt2e/W5DR1hetnMnTyeZTGpeo/soO1ZPtBtZq5Cm8d+L kiaE5uhITs9CaWajVoYvrs70fQEmtRPSqimUzAjQxhed7pOzXTv1RXtf3629ZYMNiRzerIfdf6a S40qXJcszGfxgZNOEyCsXKk3KbS79t21oNh+z/RcHGS7bJCtD3NWeGEhX6ZzFrHK2htddzmQ2Oh fAtYyeZTre6BeZSV4sn+gnpBXWBjVmExz1VkPzo7VfUR0tTm2XXvBUXyECvcpvQd2cxr6aT5ZMF OK4oST6u1gPV9gu6ekGJGm+bDERbS2dM5vxU42+XchVFOpShXw8wgfMCXQJfvcpmwdowMzcvIEr HJBkSK/L4KKQf X-Received: by 2002:a05:6000:2387:b0:431:3a5:d9b2 with SMTP id ffacd0b85a97d-435dd1c1d77mr12493989f8f.39.1769684886722; Thu, 29 Jan 2026 03:08:06 -0800 (PST) X-Received: by 2002:a05:6000:2387:b0:431:3a5:d9b2 with SMTP id ffacd0b85a97d-435dd1c1d77mr12493963f8f.39.1769684886252; Thu, 29 Jan 2026 03:08:06 -0800 (PST) Received: from [192.168.88.32] ([212.105.153.56]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10e474csm13833115f8f.2.2026.01.29.03.08.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jan 2026 03:08:05 -0800 (PST) Message-ID: Date: Thu, 29 Jan 2026 12:08:04 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 net 1/2] net: vlan: always set hard_header_len with VLAN_HLEN To: Chen Zhen , davem@davemloft.net, edumazet@google.com, kuba@kernel.org, horms@kernel.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, huyizhen2@huawei.com, gaoxingwang1@huawei.com References: <20260126040426.2570396-1-chenzhen126@huawei.com> <20260126040426.2570396-2-chenzhen126@huawei.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20260126040426.2570396-2-chenzhen126@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/26/26 5:04 AM, Chen Zhen wrote: > When tx-vlan-hw-insert is toggled to on, vlan device hard_header_len > will be reduced to dev->hard_header_len since commit 029f5fc31cdb > ("8021q: set hard_header_len when VLAN offload features are toggled"), > but the header_ops remains unchanged, ndisc skb will be allocated > with this len and filled in vlan hdr in vlan_dev_hard_header(), but > with reorder_hdr off, the skb room is not enough so it triggers > skb_panic() as below: > > skbuff: skb_under_panic: text:ffffffffa0535126 len:90 put:14 > head:ffff916c04232ec0 data:ffff916c04232ebe tail:0x58 end:0x180 dev:veth0.10 > ------------[ cut here ]------------ > kernel BUG at net/core/skbuff.c:197! > > skb_push+0x39/0x40 net/core/skbuff.c:207 > eth_header+0x26/0xb0 net/ethernet/eth.c:90 > vlan_dev_hard_header+0x58/0x130 net/8021q/vlan_dev.c:85 [8021q] > neigh_connected_output+0xae/0x100 net/core/neighbour.c:1589 > ip6_finish_output2+0x2cc/0x650 net/ipv6/ip6_output.c:213 > ip6_finish_output+0x27/0xd0 net/ipv6/ip6_output.c:246 > ndisc_send_skb+0x1d0/0x370 net/ipv6/ndisc.c:516 > ndisc_send_ns+0x5a/0xb0 net/ipv6/ndisc.c:672 > addrconf_dad_work+0x2b5/0x380 net/ipv6/addrconf.c:4258 > process_one_work+0x17f/0x320 kernel/workqueue.c:2743 > > In case of possible crash from other callers, fix this by always > reserving VLAN_HLEN in hard_header_len even if the header_ops would > not request it. > > Fixes: 029f5fc31cdb ("8021q: set hard_header_len when VLAN offload features are toggled") > Signed-off-by: Chen Zhen > --- > net/8021q/vlan.c | 5 ----- > net/8021q/vlan_dev.c | 8 +++----- > 2 files changed, 3 insertions(+), 10 deletions(-) > > diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c > index 2b74ed56eb16..a7b5da7f9999 100644 > --- a/net/8021q/vlan.c > +++ b/net/8021q/vlan.c > @@ -323,11 +323,6 @@ static void vlan_transfer_features(struct net_device *dev, > > 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; > - > #if IS_ENABLED(CONFIG_FCOE) > vlandev->fcoe_ddp_xid = dev->fcoe_ddp_xid; > #endif > diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c > index fbf296137b09..9e81669bffd6 100644 > --- a/net/8021q/vlan_dev.c > +++ b/net/8021q/vlan_dev.c > @@ -572,13 +572,11 @@ static int vlan_dev_init(struct net_device *dev) > #endif > > dev->needed_headroom = real_dev->needed_headroom; > - if (vlan_hw_offload_capable(real_dev->features, vlan->vlan_proto)) { > + dev->hard_header_len = real_dev->hard_header_len + VLAN_HLEN; I'm wondering if the above would foul hard_header_len users to do wrong/bad mac comparison, i.e. in gro_list_prepare() ? /P