Re: [PATCH net v2] net: stmmac: fix oops when split header is enabled

On Fri, Feb 06, 2026 at 02:56:38PM -0500, Jie Zhang wrote:

quoted

For GMAC4, when split header is enabled, in some rare cases, the
hardware does not fill buf2 of the first descriptor with payload.
Thus we cannot assume buf2 is always fully filled if it is not
the last descriptor. Otherwise, the length of buf2 of the second
descriptor will be calculated wrong and cause an oops:

Unable to handle kernel paging request at virtual address ffff00019246bfc0
...
x2 : 0000000000000040 x1 : ffff00019246bfc0 x0 : ffff00009246c000
Call trace:
 dcache_inval_poc+0x28/0x58 (P)
 dma_direct_sync_single_for_cpu+0x38/0x6c
 __dma_sync_single_for_cpu+0x34/0x6c
 stmmac_napi_poll_rx+0x8f0/0xb60
 __napi_poll.constprop.0+0x30/0x144
 net_rx_action+0x160/0x274
 handle_softirqs+0x1b8/0x1fc
...

To fix this, the PL bit-field in RDES3 register is used for all
descriptors, whether it is the last descriptor or not.

Fixes: ec222003bd94 ("net: stmmac: Prepare to add Split Header support")
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Jie Zhang <redacted>
---
v2:
1. Update for the latest net HEAD
2. Reduce crash dump message in commit message
3. Add Fixes tag
v1 link: https://lore.kernel.org/all/20251202025421.4560-1-jie.zhang@analog.com/ (local)

I was trying to work out whether this was a re-post of a patch that had
already been merged and it was the result of someone inappropriately
re-posting old patches, or whether it was something to take seriously.

That is because of this in the patch:

quoted

+	/* Not GMAC4 and not last descriptor */
+	if (!priv->plat->has_gmac4 && (status & rx_not_ls))

Commit 26ab9830beab ("net: stmmac: replace has_xxxx with core_type"):

diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 99022620457a..151c81c560c8 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h

...
+       enum dwmac_core_type core_type;
...
-       int has_gmac4;

So, has_gmac4 no longer exists, and hasn't done since October last
year.

Thus, it seems your patch has been generated against an old kernel.
As you are submitting for netdev, it is a good idea to ensure that
patches apply to the net-next tree and/or net tree depending on
which one you are targetting, and have been tested against that
tree.