All of lore.kernel.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2026-08-18  1:22 UTC|newest]

Thread overview: 8+ 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]
2026-08-24 12:13   ` Pascal Kneuper
2026-08-24 12:50 ` [PATCH net v2] net: stmmac: restore NET_IP_ALIGN in the RX DMA offset Pascal Kneuper
2026-08-24 14:23   ` David Laight
2026-08-27 19:40   ` patchwork-bot+netdevbpf
2026-09-08  8:16   ` Maxime Chevallier
     [not found]     ` <5aeb6fd1-f1c3-426d-a2c4-1ad45ddc8572@bootlin.com>
2026-09-09  8:57       ` Pascal Kneuper

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 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.