All of lore.kernel.org
 help / color / mirror / Atom feed
From: 赵金明 <zhaojinming@uniontech.com>
To: maxime.chevallier <maxime.chevallier@bootlin.com>,
	 andrew+netdev <andrew+netdev@lunn.ch>,
	 davem <davem@davemloft.net>,  edumazet <edumazet@google.com>,
	 kuba <kuba@kernel.org>,  pabeni <pabeni@redhat.com>,
	 mcoquelin.stm32 <mcoquelin.stm32@gmail.com>,
	 alexandre.torgue <alexandre.torgue@foss.st.com>,
	 jose.abreu <Jose.Abreu@synopsys.com>
Cc: netdev <netdev@vger.kernel.org>,
	 linux-stm32 <linux-stm32@st-md-mailman.stormreply.com>,
	 linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net] net: stmmac: fix stale descriptors and DMA mapping leak on Tx map failure
Date: Fri, 11 Sep 2026 16:40:33 +0800	[thread overview]
Message-ID: <E92AD2C7F9C27CD6+202609111640319095245@uniontech.com> (raw)
In-Reply-To: 4a07a3d6-b515-43b6-918d-87806c479430@bootlin.com



>Hi,



>



>On 9/10/26 07:19, ZhaoJinming wrote:



>> In stmmac_xmit(), when the DMA mapping of the linear part or of a



>> fragment fails, the error path only frees the skb.? This leaves behind



>> the DMA mappings already created for the linear part and for the



>> fragments mapped before the failure, which are never unmapped.



>> 



>> The VLAN context descriptor programmed by stmmac_vlan_insert() is also



>> left behind with its OWN bit set while tx_q->cur_tx has been advanced



>> past it, so the DMA engine later consumes the orphaned descriptor and



>> applies its stale VLAN tag to an unrelated frame.



>> 



>> Release the descriptors and their DMA mappings in the dma_map_err path



>> with stmmac_release_tx_desc() and stmmac_free_tx_buffer(), walking from



>> first_entry to entry, then roll back tx_q->cur_tx and release the VLAN



>> context descriptor.



>> 



>> Fixes: 30d932279dc2 ("net: stmmac: Add support for VLAN Insertion Offload")



>> Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>



>> ---



>>? drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 29 +++++++++++++++++++----



>>? 1 file changed, 25 insertions(+), 4 deletions(-)



>> 



>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c



>> index 24656b35350b14454fb10deced6516eb89e2c0c9..2e36c27e2cfb436af3566cf1c3e70d32ce9830a0 100644



>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c



>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c



>> @@ -4769,12 +4769,12 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)



>>? 	unsigned int nopaged_len = skb_headlen(skb);



>>? 	u32 queue = skb_get_queue_mapping(skb);



>>? 	int nfrags = skb_shinfo(skb)->nr_frags;



>> -	unsigned int first_entry, tx_packets;



>> +	unsigned int first_entry, entry, tx_packets;



>>? 	struct stmmac_txq_stats *txq_stats;



>>? 	struct dma_desc *desc, *first_desc;



>>? 	struct stmmac_tx_queue *tx_q;



>>? 	int i, csum_insertion = 0;



>> -	int entry, first_tx;



>> +	int first_tx, ret;



>>? 	dma_addr_t dma_addr;



>>? 	u32 sdu_len;



>



>Please follow the reverse xmas tree ordering, from longest line to shortest

Done in v2: the variable declarations in stmmac_xmit() are now ordered
from longest to shortest line.



>



>The rest seems OK. By any chance, do you have a reproducer ?



>



>Maxime



>



>

No runtime reproducer, sorry. This was found by code review / static
analysis. The trigger requires a DMA mapping failure (dma_map_single /
skb_frag_dma_map) combined with VLAN insertion offload or fragmented
SKBs, which needs IOMMU pressure or fault injection to reproduce
reliably.

Thanks for the review.

Regards,
ZhaoJinming



  reply	other threads:[~2026-09-11  8:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10  5:19 [PATCH net] net: stmmac: fix stale descriptors and DMA mapping leak on Tx map failure ZhaoJinming
2026-09-10  8:51 ` Maxime Chevallier
2026-09-11  8:40   ` 赵金明 [this message]
2026-09-10  9:22 ` Lorenzo Bianconi
2026-09-11  8:34   ` 赵金明

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=E92AD2C7F9C27CD6+202609111640319095245@uniontech.com \
    --to=zhaojinming@uniontech.com \
    --cc=Jose.Abreu@synopsys.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --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 \
    /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.