From: Jakub Kicinski <kuba@kernel.org>
To: PKneuper@dspace.de
Cc: Jakub Kicinski <kuba@kernel.org>,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk,
maxime.chevallier@bootlin.com, 0x1207@gmail.com,
si.yanteng@linux.dev, larysa.zaremba@intel.com,
aleksander.lobakin@intel.com, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, DBaldin@dspace.de
Subject: Re: [PATCH net] net: stmmac: restore NET_IP_ALIGN in the non-XDP RX path
Date: Mon, 17 Aug 2026 18:22:17 -0700 [thread overview]
Message-ID: <20260818012216.3825070-2-kuba@kernel.org> (raw)
In-Reply-To: <20260813092923.284285-1-PKneuper@dspace.de>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: stmmac: restore NET_IP_ALIGN in the non-XDP RX path
This adds NET_IP_ALIGN back to the RX DMA offset returned by
stmmac_rx_offset() for the non-XDP case, so that the page pool page handed
to the stack as the skb head places the IP header at a 4-byte aligned
address again. Without it, ARM32 takes an alignment exception in
icmp_echo() for any received echo request.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index a71f0df263785..2a57415be25cf 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1529,7 +1529,7 @@ static unsigned int stmmac_rx_offset(struct stmmac_priv *priv)
> if (stmmac_xdp_is_enabled(priv))
> return XDP_PACKET_HEADROOM;
>
> - return NET_SKB_PAD;
> + return NET_SKB_PAD + NET_IP_ALIGN;
> }
[Severity: High]
Should the XDP branch of stmmac_rx_offset() get the same treatment?
When an XDP program is attached, stmmac_rx_offset() returns bare
XDP_PACKET_HEADROOM (256) with no NET_IP_ALIGN, and an XDP_PASS packet goes
to the stack through exactly the code this patch is fixing, in stmmac_rx():
skb = napi_build_skb(page_address(buf->page),
rx_q->napi_skb_frag_size);
...
/* XDP program may adjust header */
head_pad_len = ctx.xdp.data - ctx.xdp.data_hard_start;
skb_reserve(skb, head_pad_len);
skb_put(skb, buf1_len);
For a program that returns XDP_PASS without touching the head, head_pad_len
is 256, so the Ethernet header starts at 256, the IP header at 270 and the
ICMP or TCP header at 290:
290 % 4 == 2
which is the same 2 mod 4 misalignment class as the 98 in the reported
crash, so the icmp_echo() panic quoted in the commit message looks
reproducible on the same board by attaching an XDP_PASS program.
The 2021 commit a955318fe67e ("stmmac: align RX buffers") cited in the
commit message changed both returns (XDP_PACKET_HEADROOM + NET_IP_ALIGN as
well); here only one return changes, leaving the two branches of the same
helper with different alignment guarantees.
Page pool sizing is derived from stmmac_rx_offset() for both branches in
__alloc_dma_rx_desc_resources():
dma_buf_sz_pad = stmmac_rx_offset(priv) + dma_conf->dma_buf_sz +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
num_pages = DIV_ROUND_UP(dma_buf_sz_pad, PAGE_SIZE);
so wouldn't the extra two bytes be accounted for in the XDP case too?
If the intent is to fix only the non-XDP configuration, could the commit
message say so explicitly, since stable backporters and anyone running XDP
on ARM32 would still hit the panic?
Cross-instance finding from sashiko-gemini (bb586704729c8cac27b6f004c29082ebde7dad94593b943d82d5139137628cdb):
[Severity: Critical]
Hardware DMA address truncation and silent packet corruption due to unaligned RX offset.
--
pw-bot: cr
prev parent reply other threads:[~2026-08-18 1:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 9:29 [PATCH net] net: stmmac: restore NET_IP_ALIGN in the non-XDP RX path Pascal Kneuper
2026-08-18 1:22 ` Jakub Kicinski [this message]
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=20260818012216.3825070-2-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=0x1207@gmail.com \
--cc=DBaldin@dspace.de \
--cc=PKneuper@dspace.de \
--cc=aleksander.lobakin@intel.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=larysa.zaremba@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rmk+kernel@armlinux.org.uk \
--cc=si.yanteng@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox