All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tianyi Gao <tianyi@cloudflare.com>
To: netdev@vger.kernel.org
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	Stanislav Fomichev <sdf@fomichev.me>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	Toke Hoiland-Jorgensen <toke@redhat.com>,
	linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
	kernel-team@cloudflare.com, Tianyi Gao <tianyi@cloudflare.com>
Subject: [PATCH net 0/2] net: fix mac_len of skbs copied by generic XDP
Date: Tue,  3 Nov 2026 20:00:35 +0000	[thread overview]
Message-ID: <20261103200036.65764-2-tianyi@cloudflare.com> (raw)

Generic XDP copies the skb before it runs a program with frags support.
The copy happens when the skb is cloned, nonlinear, or has less than 256
bytes of headroom. skb_pp_cow_data() makes the copy, but it does not
copy mac_len. After XDP, the skb has mac_len 0.

Two places after generic XDP move skb->data by mac_len:
- On XDP_REDIRECT to a cpumap, cpu_map_generic_redirect() pulls mac_len
  bytes, the length of the Ethernet header. Then it queues the skb to
  the target CPU. With mac_len 0, the IP layer on that CPU sees the
  Ethernet header and drops the packet.
- On XDP_PASS, the skb can go on to tc ingress with a BPF program
  attached (tcx, cls_bpf or act_bpf). Before it runs the program, tc
  pushes mac_len bytes, the length of the Ethernet header. With
  mac_len 0, skb->data stays at the IP header. Therefore, the program
  reads the IP header as the Ethernet header.

Patch 1 copies mac_len in skb_pp_cow_data(). Patch 2 adds a test to
drivers/net/ping.py. The test redirects packets to a cpumap in generic
XDP. On netdevsim, the test fails without patch 1.

---
Copying mac_len in __copy_skb_header() would cover every caller. But it
would also change skb_copy(), pskb_copy() and skb_copy_expand().
Commit 6001896f0098 ("bpf: Run generic devmap egress prog on private
skb") hit a similar problem. It copies mac_len right after skb_copy() in
dev_map_generic_redirect() [1]. We followed that approach.

The bug can be reproduced on veth, virtio_net and netdevsim. The fix was
tested on all three. Native XDP is not affected.

[1] https://lore.kernel.org/all/CABFUUZFQXxYVdi_QqhGG8WTTf=F1BqOmroYj50mv0w70Acf5Bw@mail.gmail.com/

Tianyi Gao (2):
  net: fix mac_len of skbs copied by generic XDP
  selftests: drv-net: ping: test generic XDP redirect to cpumap

 net/core/skbuff.c                             |  1 +
 tools/testing/selftests/drivers/net/ping.py   | 27 ++++++++++++++++---
 .../selftests/net/lib/xdp_cpumap.bpf.c        | 19 +++++++++++++
 3 files changed, 44 insertions(+), 3 deletions(-)
 create mode 100644 tools/testing/selftests/net/lib/xdp_cpumap.bpf.c


base-commit: 647b81ddefc6364290e67bf33c89d54971f8995e
-- 
2.55.0


             reply	other threads:[~2026-11-03 20:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 20:00 Tianyi Gao [this message]
2026-11-03 20:00 ` [PATCH net 1/2] net: fix mac_len of skbs copied by generic XDP Tianyi Gao
2026-11-06 10:34   ` Toke Høiland-Jørgensen
2026-11-03 20:00 ` [PATCH net 2/2] selftests: drv-net: ping: test generic XDP redirect to cpumap Tianyi Gao
2026-11-03 20:04 ` [PATCH net 0/2] net: fix mac_len of skbs copied by generic XDP netdev-bot+sinfo
2026-11-03 20:53   ` Tianyi Gao
2026-11-10 14:30 ` patchwork-bot+netdevbpf

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=20261103200036.65764-2-tianyi@cloudflare.com \
    --to=tianyi@cloudflare.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=hawk@kernel.org \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kernel-team@cloudflare.com \
    --cc=kuba@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=toke@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.