From: vladimir.oltean@nxp.com
To: netdev@vger.kernel.org
Cc: Zefir Kurtisi <zefir.kurtisi@westermo.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Wei Fang <wei.fang@nxp.com>, Clark Wang <xiaoning.wang@nxp.com>,
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>,
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>,
Simon Horman <horms@kernel.org>,
Richard Cochran <richardcochran@gmail.com>,
Yangbo Lu <yangbo.lu@nxp.com>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org
Subject: [PATCH v3 net 5/7] net: enetc: pad short XDP frames coming from devmap
Date: Wed, 16 Sep 2026 01:27:32 +0300 [thread overview]
Message-ID: <20260915222735.1016937-6-vladimir.oltean@nxp.com> (raw)
In-Reply-To: <20260915222735.1016937-1-vladimir.oltean@nxp.com>
Similar to the skb path issue explained in the previous change, ENETC
could end up transmitting short frames coming from XDP.
The way in which this could happen is a bit contrived, but it involves
XDP_REDIRECT from a veth interface pair.
As for enetc_xmit(), there are two separate limitations for the overall
FRM_LEN and for the head BUFF_LEN. For the head BUFF_LEN, we add a
direct restriction in enetc_xdp_xmit(), and for the overall FRM_LEN, we
introduce a xdp_frame_pad() best-effort generic helper which we call
from the same place.
This helper alters the frame, but that should be safe, because
ndo_xdp_xmit() is the hand-off function where the XDP frames become the
responsibility of the driver. AFAIU, struct xdp_frame doesn't have
multiple copies.
I say best-effort because xdp_frame_pad() can only expand the head
buffer of an XDP frame. It cannot expand the last fragment of a
multi-buffer XDP frame, because, unlike bpf_xdp_frags_increase_tail(),
it lacks access to the rxq->frag_size, aka the capacity of the chunk of
memory being pointed to by the fragment.
So, if the frame happens to be less than minimum Ethernet size, but
fragmented, callers of this function will have to drop it.
Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2->v3: none
v1->v2:
- handle multi-buffer frames instead of being unaware of their
multi-buffer quality
- add separate restriction for BUFF_LEN
- increment drop counter
---
drivers/net/ethernet/freescale/enetc/enetc.c | 14 +++++++++---
include/net/xdp.h | 23 ++++++++++++++++++++
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index bbad942041f5..8a9ba168eab1 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1838,15 +1838,23 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
prefetchw(ENETC_TXBD(*tx_ring, tx_ring->next_to_use));
for (k = 0; k < num_frames; k++) {
- if (xdp_frame_has_frags(frames[k])) {
- shinfo = xdp_get_shared_info_from_frame(frames[k]);
+ struct xdp_frame *xdpf = frames[k];
+
+ if (xdp_frame_has_frags(xdpf)) {
+ shinfo = xdp_get_shared_info_from_frame(xdpf);
if (unlikely((shinfo->nr_frags + 1) > ENETC_MAX_SKB_FRAGS))
break;
}
+ if (unlikely(xdp_frame_pad(xdpf) ||
+ xdpf->len < ENETC_MIN_BUFF_SIZE)) {
+ tx_ring->stats.xdp_tx_drops++;
+ break;
+ }
+
xdp_tx_bd_cnt = enetc_xdp_frame_to_xdp_tx_swbd(tx_ring,
xdp_redirect_arr,
- frames[k]);
+ xdpf);
if (unlikely(xdp_tx_bd_cnt < 0))
break;
diff --git a/include/net/xdp.h b/include/net/xdp.h
index aa742f413c35..276afc9aa21d 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -477,6 +477,29 @@ xdp_get_frame_len(const struct xdp_frame *xdpf)
return len;
}
+static inline int xdp_frame_pad(struct xdp_frame *xdpf)
+{
+ unsigned int total_len, pad;
+ void *sinfo;
+
+ total_len = xdp_get_frame_len(xdpf);
+ if (likely(total_len >= ETH_ZLEN))
+ return 0;
+
+ if (unlikely(xdp_frame_has_frags(xdpf)))
+ return -EOPNOTSUPP;
+
+ pad = ETH_ZLEN - total_len;
+ sinfo = xdp_get_shared_info_from_frame(xdpf);
+ if (unlikely(xdpf->data + xdpf->len + pad > sinfo))
+ return -ENOMEM;
+
+ memset(xdpf->data + xdpf->len, 0, pad);
+ xdpf->len += pad;
+
+ return 0;
+}
+
int __xdp_rxq_info_reg(struct xdp_rxq_info *xdp_rxq,
struct net_device *dev, u32 queue_index,
unsigned int napi_id, u32 frag_size);
--
2.43.0
next prev parent reply other threads:[~2026-09-15 22:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 22:27 [PATCH v3 net 0/7] Fix short frame transmission in enetc vladimir.oltean
2026-09-15 22:27 ` [PATCH v3 net 1/7] net: enetc: consistenly track dropped frames in enetc_xdp_xmit() vladimir.oltean
2026-09-16 2:16 ` Wei Fang
2026-09-18 10:27 ` Vladimir Oltean
2026-09-16 23:35 ` netdev-bot+sashiko
2026-09-15 22:27 ` [PATCH v3 net 2/7] net: enetc: ensure enetc_xdp_xmit() calls enetc_update_tx_ring_tail() vladimir.oltean
2026-09-16 2:20 ` Wei Fang
2026-09-16 23:35 ` netdev-bot+sashiko
[not found] ` <20260916222806.6011F1F00893@smtp.kernel.org>
2026-09-18 23:05 ` Vladimir Oltean
2026-09-15 22:27 ` [PATCH v3 net 3/7] net: enetc: fix bogus TX ring consumer index after reinitialization vladimir.oltean
2026-09-15 22:27 ` [PATCH v3 net 4/7] net: enetc: pad short frames in software vladimir.oltean
2026-09-16 23:35 ` netdev-bot+sashiko
2026-09-17 10:11 ` David Laight
2026-09-21 11:29 ` Vladimir Oltean
2026-09-15 22:27 ` vladimir.oltean [this message]
2026-09-16 23:35 ` [PATCH v3 net 5/7] net: enetc: pad short XDP frames coming from devmap netdev-bot+sashiko
2026-09-15 22:27 ` [PATCH v3 net 6/7] net: enetc: linearize PTP event packets with one-step TX timestamping vladimir.oltean
2026-09-16 1:59 ` Wei Fang
2026-09-16 9:50 ` Vladimir Oltean
2026-09-16 23:35 ` netdev-bot+sashiko
2026-09-15 22:27 ` [PATCH v3 net 7/7] net: enetc: drain and cancel one-step TX tstamp queue when going down vladimir.oltean
2026-09-16 23:36 ` 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=20260915222735.1016937-6-vladimir.oltean@nxp.com \
--to=vladimir.oltean@nxp.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=claudiu.manoil@nxp.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=imx@lists.linux.dev \
--cc=ioana.ciornei@nxp.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=sdf@fomichev.me \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.com \
--cc=yangbo.lu@nxp.com \
--cc=zefir.kurtisi@westermo.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