From: Jakub Kicinski <kuba@kernel.org>
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com,
andrew+netdev@lunn.ch, horms@kernel.org, jv@jvosburgh.net,
hawk@kernel.org, sdf@fomichev.me, emil@etsalapatis.com,
liuhangbin@gmail.com, bpf@vger.kernel.org,
linux-kselftest@vger.kernel.org, willemdebruijn.kernel@gmail.com,
aleksander.lobakin@intel.com, Jakub Kicinski <kuba@kernel.org>
Subject: [PATCH net-next 5/5] net: drop GSO skbs instead of handing them to XDP
Date: Mon, 28 Sep 2026 15:36:48 -0700 [thread overview]
Message-ID: <20260928223648.2739371-6-kuba@kernel.org> (raw)
In-Reply-To: <20260928223648.2739371-1-kuba@kernel.org>
skb BPF paths have a number of helpers to fix up the GSO
state after packet modifications. XDP has no such support.
"Real" / driver XDP runs before the SW GRO, and drivers generally
disable HW-GRO when XDP is attached (with the exception of IDPF,
story for another time), so this is not an issue. We also try
to disable HW-GRO and elide SW GRO when generic XDP prog is
attached. These precautions are not 100% today, and IMHO fixing
that is impossible. Let's explicitly drop GSO skbs on input to XDP.
First example how things can go sideways today - bonding.
We only disable & elide GRO on the device to which program is
attached. Nothing reaches the devices below it, and for a stacked
device that is where the packets come from:
ip link set dev bond0 xdpgeneric obj prog.o sec xdp
leaves every slave with GRO on and no xdp_prog of its own, so
netif_elide_gro() lets them coalesce as usual. bond_handle_frame()
then returns RX_HANDLER_ANOTHER, __netif_receive_skb_core() loops back
round to another_round with skb->dev switched to the bond, and the
program gets handed a packet which was never on the wire. HW-GRO is
the same story - while netif_disable_lro() walks the lower devices,
its HW-GRO counterpart never did (this is largely the point of
distinguishing between LRO and HW-GRO).
Example two - veth. Generic XDP on a veth gets there by a different route.
veth_xdp_set() takes NETIF_F_GSO_SOFTWARE away from the peer so that
no GSO skb is ever built for a device running XDP, but generic XDP does
not go through ndo_bpf, so none of that happens.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
include/net/xdp.h | 16 ++++++++++++++++
drivers/net/veth.c | 3 +++
net/core/dev.c | 4 ++++
3 files changed, 23 insertions(+)
diff --git a/include/net/xdp.h b/include/net/xdp.h
index aa742f413c35..5a234aab1e1c 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -291,6 +291,22 @@ static inline bool xdp_buff_add_frag(struct xdp_buff *xdp, netmem_ref netmem,
return true;
}
+/**
+ * xdp_skb_feature_check() - can this skb be handed to an XDP program?
+ * @skb: skb about to be turned into an xdp_buff
+ *
+ * Return: true if the skb must not reach the program and has to be dropped.
+ */
+static inline bool xdp_skb_feature_check(const struct sk_buff *skb)
+{
+ if (likely(!skb_is_gso(skb)))
+ return false;
+
+ net_warn_ratelimited("%s: dropping coalesced packet before XDP, receive offloads are still on\n",
+ skb->dev->name);
+ return true;
+}
+
struct xdp_frame {
void *data;
u32 len;
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 71227d0389aa..5635037e3b60 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -756,6 +756,9 @@ static int veth_convert_skb_to_xdp_buff(struct veth_rq *rq,
struct sk_buff *skb = *pskb;
u32 frame_sz;
+ if (unlikely(xdp_skb_feature_check(skb)))
+ goto drop;
+
if (skb_shared(skb) || skb_head_is_locked(skb) ||
skb_is_nonlinear(skb) ||
skb_headroom(skb) < XDP_PACKET_HEADROOM) {
diff --git a/net/core/dev.c b/net/core/dev.c
index 096d1dedebfd..fbeb3df4c11f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -158,6 +158,7 @@
#include <linux/once_lite.h>
#include <net/netdev_lock.h>
#include <net/netdev_rx_queue.h>
+#include <net/xdp.h>
#include <net/page_pool/types.h>
#include <net/page_pool/helpers.h>
#include <net/page_pool/memory_provider.h>
@@ -5516,6 +5517,9 @@ u32 bpf_prog_run_generic_xdp(struct sk_buff *skb, struct xdp_buff *xdp,
u32 metalen, act;
int off;
+ if (unlikely(xdp_skb_feature_check(skb)))
+ return XDP_DROP;
+
/* The XDP program wants to see the packet starting at the MAC
* header.
*/
--
2.55.0
next prev parent reply other threads:[~2026-09-28 22:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 22:36 [PATCH net-next 0/5] net: fix a couple of problems with XDP and bonding Jakub Kicinski
2026-09-28 22:36 ` [PATCH net-next 1/5] net: record XDP programs propagated to lower devices Jakub Kicinski
2026-09-29 22:36 ` sashiko-bot
2026-09-29 23:32 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
2026-09-28 22:36 ` [PATCH net-next 2/5] netdevsim: add ndo_xdp_xmit Jakub Kicinski
2026-09-29 23:32 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
2026-09-28 22:36 ` [PATCH net-next 3/5] selftests: drv-net: check tcp-data-split against an already attached XDP Jakub Kicinski
2026-09-29 23:32 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
2026-09-28 22:36 ` [PATCH net-next 4/5] selftests/bpf: check XDP attach on a nested bond slave Jakub Kicinski
2026-09-29 22:37 ` sashiko-bot
2026-09-29 23:32 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
2026-09-28 22:36 ` Jakub Kicinski [this message]
2026-09-29 22:37 ` [PATCH net-next 5/5] net: drop GSO skbs instead of handing them to XDP sashiko-bot
2026-09-29 23:33 ` Stanislav Fomichev
2026-09-30 4:38 ` netdev-bot+sashiko
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=20260928223648.2739371-6-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=emil@etsalapatis.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=jv@jvosburgh.net \
--cc=linux-kselftest@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=willemdebruijn.kernel@gmail.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.