From: Martin KaFai Lau <martin.lau@linux.dev>
To: nhudson@akamai.com
Cc: bot+bpf-ci@kernel.org, bpf@vger.kernel.org,
netdev@vger.kernel.org, willemb@google.com, mtottenh@akamai.com,
aglasgal@akamai.com, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, eddyz87@gmail.com, memxor@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, linux-kernel@vger.kernel.org,
martin.lau@kernel.org, yonghong.song@linux.dev, clm@meta.com,
ihor.solodrai@linux.dev
Subject: Re: [PATCH v5 5/6] bpf: clear decap tunnel GSO state in skb_adjust_room
Date: Mon, 27 Apr 2026 15:19:53 -0700 [thread overview]
Message-ID: <2026427201356.-eYM.martin.lau@linux.dev> (raw)
In-Reply-To: <82df2b6834553e3f2da26e5ee1f1b880f8a1af073e6fd88894a4839c66b7b121@mail.kernel.org>
On Mon, Apr 20, 2026 at 11:19:31AM +0000, bot+bpf-ci@kernel.org wrote:
> > + if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) &&
> > + (shinfo->gso_type & (SKB_GSO_UDP_TUNNEL |
> > + SKB_GSO_UDP_TUNNEL_CSUM)))
> > + shinfo->gso_type &= ~(SKB_GSO_UDP_TUNNEL |
> > + SKB_GSO_UDP_TUNNEL_CSUM);
> > + if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_GRE) &&
> > + (shinfo->gso_type & (SKB_GSO_GRE | SKB_GSO_GRE_CSUM)))
> > + shinfo->gso_type &= ~(SKB_GSO_GRE |
> > + SKB_GSO_GRE_CSUM);
> > + if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP4) &&
> > + (shinfo->gso_type & SKB_GSO_IPXIP4))
> > + shinfo->gso_type &= ~SKB_GSO_IPXIP4;
> > + if ((flags & BPF_F_ADJ_ROOM_DECAP_IPXIP6) &&
> > + (shinfo->gso_type & SKB_GSO_IPXIP6))
> > + shinfo->gso_type &= ~SKB_GSO_IPXIP6;
> > +
> > + /* Clear encapsulation flag only when no tunnel GSO flags remain */
> > + if (flags & (BPF_F_ADJ_ROOM_DECAP_L4_MASK |
> > + BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK)) {
> > + if (!(shinfo->gso_type & (SKB_GSO_UDP_TUNNEL |
> > + SKB_GSO_UDP_TUNNEL_CSUM |
> > + SKB_GSO_GRE |
> > + SKB_GSO_GRE_CSUM |
> > + SKB_GSO_IPXIP4 |
> > + SKB_GSO_IPXIP6 |
> > + SKB_GSO_ESP)))
> > + if (skb->encapsulation)
> > + skb->encapsulation = 0;
> > + }
>
> All of this new GSO flag clearing logic is added inside the if (skb_is_gso(skb))
> block in bpf_skb_net_shrink(). Does this mean non-GSO packets bypass the
> decapsulation state clearing?
>
> BPF programs can call bpf_skb_adjust_room() to decapsulate non-GSO packets
> as well. If a non-GSO packet undergoes decapsulation with the tunnel headers
> stripped, but skb->encapsulation remains set, could this cause downstream
> network stack components to misinterpret the packet as still being
> encapsulated?
It has been asked multiple times by different AI review agents but has been
ignored afaik. Please reply/address it so they won't reiterate. From
a quick look, bpf_skb_net_grow() sets the encapsulation regardless
of skb_is_gso.
next prev parent reply other threads:[~2026-04-27 22:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 10:40 [PATCH bpf-next v5 0/6] bpf: decap flags and GSO state updates Nick Hudson
2026-04-20 10:40 ` [PATCH v5 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags Nick Hudson
2026-04-20 10:40 ` [PATCH v5 2/6] bpf: refactor masks for ADJ_ROOM flags and encap validation Nick Hudson
2026-04-20 19:42 ` Willem de Bruijn
2026-04-27 22:40 ` Martin KaFai Lau
2026-04-20 10:40 ` [PATCH v5 3/6] bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation Nick Hudson
2026-04-20 19:44 ` Willem de Bruijn
2026-04-20 10:40 ` [PATCH v5 4/6] bpf: allow new DECAP flags and add guard rails Nick Hudson
2026-04-20 19:45 ` Willem de Bruijn
2026-04-20 10:40 ` [PATCH v5 5/6] bpf: clear decap tunnel GSO state in skb_adjust_room Nick Hudson
2026-04-20 11:19 ` bot+bpf-ci
2026-04-27 22:19 ` Martin KaFai Lau [this message]
2026-04-20 19:46 ` Willem de Bruijn
2026-04-20 10:40 ` [PATCH v5 6/6] selftests/bpf: tc_tunnel validate decap GSO state Nick Hudson
2026-04-20 11:19 ` bot+bpf-ci
2026-04-27 22:36 ` 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=2026427201356.-eYM.martin.lau@linux.dev \
--to=martin.lau@linux.dev \
--cc=aglasgal@akamai.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=ihor.solodrai@linux.dev \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=memxor@gmail.com \
--cc=mtottenh@akamai.com \
--cc=netdev@vger.kernel.org \
--cc=nhudson@akamai.com \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=yonghong.song@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.