From: Sandeep Haemoon <sandeeph@loljews.com>
To: netdev@vger.kernel.org
Cc: Felix Fietkau <nbd@nbd.name>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
David S. Miller <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Russell King <linux@armlinux.org.uk>,
Daniel Golle <daniel@makrotopia.org>,
Mason Chang <mason-cw.chang@mediatek.com>,
Frank Wunderlich <frank-w@public-files.de>,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [PATCH net-next v5 1/3] net: ethernet: mtk_eth_soc: fix the RX
Date: Sat, 14 Nov 2026 00:34:14 +0200 [thread overview]
Message-ID: <patch-c279f68b0cd14ae5779a591e8241dc6c@loljews.com> (raw)
In-Reply-To: <patch-f1e62a87eb0f914e1ea52a395f465998@loljews.com>
mtk_poll_rx() keeps one dma_addr_t across the whole poll loop and only
refreshes it when a replacement buffer was mapped for the descriptor
being processed. The paths that jump straight to release_desc (no
netdev for the source port, MTK_RESETTING set, or a refill allocation
failure) re-arm the descriptor with the buffer it still holds. The
address written back must therefore come from the descriptor's own
rxd2, and the release path relies on dma_addr being DMA_MAPPING_ERROR
to select those bits.
That protection was added by commit 6e0490fc36cd ("net: ethernet:
mtk_eth_soc: fix SER panic with 4GB+ RAM") for the MTK_RESETTING path,
but commit e10a35abb3da ("net: ethernet: mtk_eth_soc: fix
uninitialized variable") moved the DMA_MAPPING_ERROR initialisation
out of the loop, so it only holds for the first iteration. From the
second iteration on, the previous descriptor's high address bits are
combined with the current descriptor's low bits in rxd1. With
MTK_36BIT_DMA and DRAM above 4 GiB the hardware then DMAs the next
frame to an address that is neither buffer, and the driver passes the
stale contents of the untouched buffer up the stack. mtk_rx_clean()
unmaps the same mismatched address during a SER, which is the panic
commit 6e0490fc36cd ("net: ethernet: mtk_eth_soc: fix SER panic with
4GB+ RAM") was fixing.
Reset dma_addr to DMA_MAPPING_ERROR at the start of every iteration,
so a descriptor that is released without a new mapping keeps its own
address bits.
Fixes: 2d75891ebc09 ("net: ethernet: mtk_eth_soc: support 36-bit DMA addressing on MT7988")
Signed-off-by: Sandeep Haemoon <sandeeph@loljews.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ad0fdc4133..a46cf54411 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2210,7 +2210,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
u8 *data, *new_data;
struct mtk_rx_dma_v2 *rxd, trxd;
int done = 0, bytes = 0;
- dma_addr_t dma_addr = DMA_MAPPING_ERROR;
+ dma_addr_t dma_addr;
int ppe_idx = 0;
while (done < budget) {
@@ -2219,6 +2219,12 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
u32 hash, reason;
int mac = 0;
+ /* The release paths below hand the descriptor back with the
+ * buffer it still holds, so only overwrite its address when
+ * a new buffer was actually mapped for it.
+ */
+ dma_addr = DMA_MAPPING_ERROR;
+
ring = mtk_get_rx_ring(eth);
if (unlikely(!ring))
goto rx_done;
--
2.53.0
next prev parent reply other threads:[~2026-11-14 0:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 22:45 [PATCH net-next v5 0/3] net: ethernet: mtk_eth_soc: 9K jumbo frame support Sandeep Haemoon
2026-11-13 22:34 ` Sandeep Haemoon [this message]
2026-11-13 22:34 ` [PATCH net-next v5 2/3] net: ethernet: mtk_eth_soc: skip page_pool Sandeep Haemoon
2026-11-13 22:40 ` [PATCH net-next v5 3/3] net: ethernet: mtk_eth_soc: add 9K jumbo Sandeep Haemoon
2026-11-14 0:22 ` [PATCH net-next v5 0/3] net: ethernet: mtk_eth_soc: 9K jumbo frame support netdev-bot+sinfo
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=patch-c279f68b0cd14ae5779a591e8241dc6c@loljews.com \
--to=sandeeph@loljews.com \
--cc=andrew+netdev@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=frank-w@public-files.de \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo@kernel.org \
--cc=mason-cw.chang@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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
all inboxes | Powered by JetHome®