The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Sun Jian <sun.jian.kdev@gmail.com>
To: netdev@vger.kernel.org
Cc: "Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@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>,
	"Kuniyuki Iwashima" <kuniyu@google.com>,
	"Hangbin Liu" <liuhangbin@gmail.com>,
	"Krishna Kumar" <krikku@gmail.com>,
	"Samiullah Khawaja" <skhawaja@google.com>,
	"Martin Karsten" <mkarsten@uwaterloo.ca>,
	"Lorenzo Bianconi" <lorenzo@kernel.org>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	"Sun Jian" <sun.jian.kdev@gmail.com>,
	maciej.fijalkowski@intel.com
Subject: [PATCH net v2 0/2] Fix skb length accounting after XDP frag adjustment
Date: Thu, 30 Jul 2026 20:23:55 -0700	[thread overview]
Message-ID: <20260731032357.6114-1-sun.jian.kdev@gmail.com> (raw)

Hi,

This series fixes skb length accounting after XDP fragment adjustment in
generic XDP and veth.

v1:
https://lore.kernel.org/bpf/20260727032535.13469-1-sun.jian.kdev@gmail.com/

Changes in v2:
- Move the veth fragment accounting before the linear tail adjustment, so
  __skb_put() observes a linear skb after a shrink removes all fragments.
- Fold the skb->len update into the xdp_buff_has_frags() branch, as suggested
  by Lorenzo Bianconi.
- Clarify why the old data_len contribution must be removed before adding the
  updated one, as requested by Maciej Fijalkowski.

Sun Jian (2):
  net: fix skb length accounting after generic XDP frag adjustment
  veth: fix skb length accounting after XDP frag adjustment

 drivers/net/veth.c | 23 +++++++++++++++--------
 net/core/dev.c     | 10 +++++++---
 2 files changed, 22 insertions(+), 11 deletions(-)

Range-diff against v1:
1:  b914fb40f348 ! 1:  2d716a1bd570 net: fix skb length accounting after generic XDP frag adjustment
    @@ Commit message
     
         Fixes: e6d5dbdd20aa ("xdp: add multi-buff support for xdp running in generic mode")
         Cc: stable@vger.kernel.org
    -    Link: https://lore.kernel.org/r/20260720141859.19FF41F000E9@smtp.kernel.org
         Link: https://lore.kernel.org/bpf/al9T9Eto%2FhRIzP5W@boxer/
         Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
     
    @@ net/core/dev.c: u32 bpf_prog_run_generic_xdp(struct sk_buff *skb, struct xdp_buf
      
      	/* XDP frag metadata (e.g. nr_frags) are updated in eBPF helpers
     -	 * (e.g. bpf_xdp_adjust_tail), we need to update data_len here.
    -+	 * (e.g. bpf_xdp_adjust_tail), update skb length fields here.
    ++	 * (e.g. bpf_xdp_adjust_tail). Remove the old fragment contribution
    ++	 * from skb->len before updating data_len, then add the new one back.
      	 */
    +-	if (xdp_buff_has_frags(xdp))
     +	skb->len -= skb->data_len;
    - 	if (xdp_buff_has_frags(xdp))
    ++	if (xdp_buff_has_frags(xdp)) {
      		skb->data_len = skb_shinfo(skb)->xdp_frags_size;
    - 	else
    +-	else
    ++		skb->len += skb->data_len;
    ++	} else {
      		skb->data_len = 0;
    -+	skb->len += skb->data_len;
    ++	}
      
      	/* check if XDP changed eth hdr such SKB needs update */
      	eth = (struct ethhdr *)xdp->data;
2:  59c79966c84a ! 2:  e5b9383bc46e veth: fix skb length accounting after XDP frag adjustment
    @@ Commit message
         Subtract the old data_len before replacing it and add the new data_len
         afterwards, keeping skb->len and skb->data_len synchronized.
     
    +    The fragment accounting must run before the linear tail adjustment:
    +    when bpf_xdp_adjust_tail() shrinks the packet into the linear area it
    +    releases all fragments, and __skb_put() requires skb->data_len == 0
    +    by that point.
    +
         A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by
         1024 bytes from its fragment area. Before the fix, all 10 runs produced
         corrupted payloads. After the fix, all 10 runs matched the expected
    @@ Commit message
     
         Fixes: 718a18a0c8a6 ("veth: Rework veth_xdp_rcv_skb in order to accept non-linear skb")
         Cc: stable@vger.kernel.org
    -    Link: https://lore.kernel.org/r/20260720141859.19FF41F000E9@smtp.kernel.org
         Link: https://lore.kernel.org/bpf/al9T9Eto%2FhRIzP5W@boxer/
         Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
     
      ## drivers/net/veth.c ##
     @@ drivers/net/veth.c: static struct sk_buff *veth_xdp_rcv_skb(struct veth_rq *rq,
    - 		__skb_put(skb, off); /* positive on grow, negative on shrink */
      
    + 	skb_reset_mac_header(skb);
    + 
    +-	/* check if bpf_xdp_adjust_tail was used */
    +-	off = xdp->data_end - orig_data_end;
    +-	if (off != 0)
    +-		__skb_put(skb, off); /* positive on grow, negative on shrink */
    +-
      	/* XDP frag metadata (e.g. nr_frags) are updated in eBPF helpers
     -	 * (e.g. bpf_xdp_adjust_tail), we need to update data_len here.
    -+	 * (e.g. bpf_xdp_adjust_tail), update skb length fields here.
    ++	 * (e.g. bpf_xdp_adjust_tail). Remove the old fragment contribution
    ++	 * from skb->len before updating data_len, then add the new one back.
    ++	 * This must precede the linear tail adjustment below: a changed
    ++	 * data_end implies that no fragments remain, and __skb_put() requires
    ++	 * a linear skb.
      	 */
    +-	if (xdp_buff_has_frags(xdp))
     +	skb->len -= skb->data_len;
    - 	if (xdp_buff_has_frags(xdp))
    ++	if (xdp_buff_has_frags(xdp)) {
      		skb->data_len = skb_shinfo(skb)->xdp_frags_size;
    - 	else
    +-	else
    ++		skb->len += skb->data_len;
    ++	} else {
      		skb->data_len = 0;
    -+	skb->len += skb->data_len;
    ++	}
    ++
    ++	/* check if bpf_xdp_adjust_tail was used */
    ++	off = xdp->data_end - orig_data_end;
    ++	if (off != 0)
    ++		__skb_put(skb, off); /* positive on grow, negative on shrink */
      
      	skb->protocol = eth_type_trans(skb, rq->dev);
      

base-commit: 97ac08560d236ca17f6606d9e671118e5eae5721
-- 
2.43.0


             reply	other threads:[~2026-07-31  3:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31  3:23 Sun Jian [this message]
2026-07-31  3:23 ` [PATCH net v2 1/2] net: fix skb length accounting after generic XDP frag adjustment Sun Jian
2026-07-31 15:45   ` Mohsin Bashir
2026-07-31 15:51   ` Lorenzo Bianconi
2026-07-31  3:23 ` [PATCH net v2 2/2] veth: fix skb length accounting after " Sun Jian
2026-07-31 16:04   ` Lorenzo Bianconi
2026-07-31 16:14   ` Mohsin Bashir

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=20260731032357.6114-1-sun.jian.kdev@gmail.com \
    --to=sun.jian.kdev@gmail.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@google.com \
    --cc=hawk@kernel.org \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=krikku@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=lorenzo@kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=mkarsten@uwaterloo.ca \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=skhawaja@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox