From: Junnan Zhang <zhangjn_dev@163.com>
To: willemdebruijn.kernel@gmail.com
Cc: davem@davemloft.net, edumazet@google.com, horms@kernel.org,
kuba@kernel.org, linux-kernel@vger.kernel.org,
liuhangbin@gmail.com, mst@redhat.com, netdev@vger.kernel.org,
pabeni@redhat.com, sunshx@chinatelecom.cn,
zhangjn11@chinatelecom.cn, zhangjn_dev@163.com
Subject: Re: [PATCH net v2] net/packet: fix network header offset for non-VLAN raw packets
Date: Tue, 1 Sep 2026 15:52:18 +0800 [thread overview]
Message-ID: <20260901075218.58914-1-zhangjn_dev@163.com> (raw)
In-Reply-To: <willemdebruijn.kernel.2a4f4a498e1ff@gmail.com>
Hi Willem,
Thanks for the detailed review.
> Where does it do this? validate_xmit_vlan does this on the physical
> device I think.
You're right. vlan_dev_hard_start_xmit() only attaches the tag metadata
via __vlan_hwaccel_put_tag(); the actual tag bytes are inserted later by
validate_xmit_vlan() on the physical device via
__vlan_hwaccel_push_inside(). I've corrected this in the v3 commit
message.
> That adds a bigger problem that the extra needed headroom of
> (hard_header_len - min_header_len) is not reserved at the start of
> the frame.
Understood. In this case it happens to work because
LL_RESERVED_SPACE_EX() rounds the reservation up, so enough headroom
remains in front of the MAC header for __vlan_insert_inner_tag() to
push the tag inside, and with the fix the MAC header correctly sits at
network_header - min_header_len. Agreed that disentangling the legacy
hard_header_len usage is beyond this bug fix targeting net; happy to
help test if you look at it for net-next.
> Instead of using min_header_len != hard_header_len to detect vlan
> devices, consider is_vlan_dev(). [...] So for now I would focus on
> the VLAN issue only.
Done in v3: the condition is now
if (sock->type == SOCK_RAW && !is_vlan_packet && is_vlan_dev(skb->dev))
and I renamed is_vlan to is_vlan_packet to avoid confusion with
is_vlan_dev(). You're also right that the ARPHRD_ETHER check excluded
the other hard_header_len cases anyway, so I scoped the subject and
commit message back to VLAN subinterfaces.
> It sucks that we have to add another branch in the hot path for an
> edge case. Would be preferable if we can fix this in the vlan driver.
> But that will come too late for skb_probe_transport_header.
Agreed - the correction has to happen before skb_probe_transport_header()
in packet_snd(), so the VLAN driver xmit path is too late.
v3 sent as a new thread with a Link to v2.
Thanks,
Junnan
prev parent reply other threads:[~2026-09-01 7:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 7:20 [PATCH net v2] net/packet: fix network header offset for non-VLAN raw packets Junnan Zhang
2026-08-31 19:18 ` Willem de Bruijn
2026-09-01 7:52 ` Junnan Zhang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260901075218.58914-1-zhangjn_dev@163.com \
--to=zhangjn_dev@163.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sunshx@chinatelecom.cn \
--cc=willemdebruijn.kernel@gmail.com \
--cc=zhangjn11@chinatelecom.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox