All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Nick Hudson" <nhudson@akamai.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v6 3/6] bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation
Date: Tue, 05 May 2026 04:14:26 +0000	[thread overview]
Message-ID: <20260505041427.787D0C2BCB4@smtp.kernel.org> (raw)
In-Reply-To: <20260504101759.3319427-4-nhudson@akamai.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The documented API behavior fails to clear tunnel modifier GSO flags, leading to SKB GSO state corruption.
--

commit b28df908f04d4d037671bd0f85e9d43e6c3ddef9
Author: Nick Hudson <nhudson@akamai.com>

bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation

This commit adds new bpf_skb_adjust_room() decapsulation flags to describe
which tunnel layer is being removed. This allows later changes to update
tunnel-related GSO state accordingly during decapsulation.

> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
[ ... ]
> + *		* **BPF_F_ADJ_ROOM_DECAP_L4_UDP**:
> + *		  Clear UDP tunnel GSO flags (SKB_GSO_UDP_TUNNEL and
> + *		  SKB_GSO_UDP_TUNNEL_CSUM) when decapsulating a UDP tunnel.

If a tunnel packet has remote checksum offload, does this documentation
imply that tunnel modifier flags like SKB_GSO_TUNNEL_REMCSUM and
SKB_GSO_PARTIAL are left intact when the base UDP flags are cleared?

[ ... ]
> + *		When using the decapsulation flags above, the skb->encapsulation
> + *		flag is automatically cleared if all tunnel-specific GSO flags
> + *		(SKB_GSO_UDP_TUNNEL, SKB_GSO_UDP_TUNNEL_CSUM, SKB_GSO_GRE,
> + *		SKB_GSO_GRE_CSUM, SKB_GSO_IPXIP4, SKB_GSO_IPXIP6) have been
> + *		removed from the packet. This handles cases where all tunnel
> + *		layers have been decapsulated.

If the base tunnel flags are cleared but tunnel modifier flags like
SKB_GSO_TUNNEL_REMCSUM remain, will the packet be left in an invalid
state where skb->encapsulation is 0 but tunnel offload features are
still present? This might cause the network stack's segmentation code to
process a packet with tunnel offload features but no actual tunnel.

Also, SKB_GSO_ESP appears to be missing from the list of tunnel-specific
GSO flags that prevent clearing skb->encapsulation. Could this result in
skb->encapsulation being cleared prematurely if an ESP tunnel is still
present?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260504101759.3319427-1-nhudson@akamai.com?part=3

  parent reply	other threads:[~2026-05-05  4:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04 10:17 [PATCH bpf-next v6 0/6] bpf: decap flags and GSO state updates Nick Hudson
2026-05-04 10:17 ` [PATCH v6 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags Nick Hudson
2026-05-04 11:03   ` bot+bpf-ci
2026-05-04 10:17 ` [PATCH v6 2/6] bpf: refactor masks for ADJ_ROOM flags and encap validation Nick Hudson
2026-05-04 11:03   ` bot+bpf-ci
2026-05-19 10:40     ` Hudson, Nick
2026-05-04 17:14   ` Willem de Bruijn
2026-05-04 10:17 ` [PATCH v6 3/6] bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation Nick Hudson
2026-05-04 11:03   ` bot+bpf-ci
2026-05-05  4:14   ` sashiko-bot [this message]
2026-05-19 10:45     ` Hudson, Nick
2026-05-04 10:17 ` [PATCH v6 4/6] bpf: allow new DECAP flags and add guard rails Nick Hudson
2026-05-05  4:14   ` sashiko-bot
2026-05-04 10:17 ` [PATCH v6 5/6] bpf: clear decap state on skb_adjust_room shrink path Nick Hudson
2026-05-04 17:15   ` Willem de Bruijn
2026-05-05  4:14   ` sashiko-bot
2026-05-04 10:17 ` [PATCH v6 6/6] selftests/bpf: tc_tunnel - validate decap GSO and encapsulation state Nick Hudson
2026-05-05  4:14   ` sashiko-bot
2026-05-19 10:52     ` Hudson, Nick
2026-05-21 15:49       ` Martin KaFai Lau

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=20260505041427.787D0C2BCB4@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=nhudson@akamai.com \
    --cc=sashiko@lists.linux.dev \
    /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.