All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Sagi Maimon <maimon.sagi@gmail.com>
Cc: netdev@vger.kernel.org, radhey.shyam.pandey@amd.com,
	michal.simek@amd.com, andrew+netdev@lunn.ch, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	daniel@iogearbox.net, jacob.e.keller@intel.com, joe@dama.to,
	suraj.gupta2@amd.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v4] net: axienet: free outstanding TX buffers in axienet_dma_bd_release()
Date: Wed, 14 Oct 2026 19:57:16 +0100	[thread overview]
Message-ID: <20261014185716.GD83879@horms.kernel.org> (raw)
In-Reply-To: <20261007034620.1360542-1-maimon.sagi@gmail.com>

On Wed, Oct 07, 2026 at 06:46:20AM +0300, Sagi Maimon wrote:
> axienet_dma_bd_release() walks the RX ring to unmap and free every
> receive buffer before releasing it, but frees the TX descriptor ring
> with dma_free_coherent() alone.  Any descriptor that
> axienet_free_tx_chain() had not yet reclaimed still holds its skb and
> its streaming DMA mapping, and both are lost.
> 
> axienet_stop() disables TX NAPI and stops the DMA engine before calling
> it, so nothing reclaims those descriptors afterwards.  Bringing the
> interface down while frames are in flight therefore leaks up to
> lp->tx_bd_num skbs and mappings each time.
> 
> axienet_dma_err_handler() already walks the TX ring this way before it
> restarts the DMA engine: it unmaps every descriptor whose cntrl is still
> set - axienet_free_tx_chain() clears it on reclaim - frees any skb still
> attached, and clears the descriptor.  Move that loop into a helper,
> axienet_free_tx_bufs(), and call it from axienet_dma_bd_release() too.
> This relies on axienet_stop() having stopped the DMA engine first, as
> the RX walk in the same function already does.  The helper frees the
> skbs with dev_kfree_skb_any(), as drops: in the error handler, which
> runs from a workqueue, that frees them directly rather than deferring
> them to softirq as dev_kfree_skb_irq() did.
> 
> The walk must not run on a ring that is not there.  axienet_open() does
> not check the result of the reset that runs axienet_dma_bd_init(), so
> when that reset fails tx_bd_v is either still NULL or, after an earlier
> close, points at the ring that close freed.  Clear tx_bd_v and rx_bd_v
> once their rings are freed, and skip the walk when tx_bd_v is NULL.
> That also ends the second dma_free_coherent() of a stale ring which the
> same path already did.  On the axienet_dma_bd_init() error path the TX
> ring has just been allocated zeroed, so the walk does nothing.
> 
> This was reported by the Sashiko AI review bot.
> 
> Tested on the AXI Ethernet MAC of an ADVA TimeCard X2 (PCIe card, with
> the built-in AXI DMA): traffic passes, and after each of ten down/up
> cycles and five module reloads, all made with traffic running and each
> running axienet_dma_bd_release(), traffic resumes and nothing is logged.
> The leak itself was not measured, and neither the failed-reset paths nor
> axienet_dma_err_handler() were exercised.
> 
> Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
> Reviewed-by: Joe Damato <joe@dama.to>
> Assisted-by: LLM sparse
> Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>

Reviewed-by: Simon Horman <horms@kernel.org>

In future please post new patch revisions as new email threads,
not as a reply to an earlier revision.

Thanks!



  parent reply	other threads:[~2026-10-14 18:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-04  8:37 [PATCH net v3] net: axienet: free outstanding TX buffers in axienet_dma_bd_release() Sagi Maimon
2026-10-05 23:41 ` Joe Damato
2026-10-06  3:44   ` Sagi Maimon
2026-10-07  1:02     ` Jakub Kicinski
2026-10-11  8:46       ` Daniel Machon
2026-10-15  7:35         ` Paolo Abeni
2026-10-15  8:03           ` Daniel Machon
2026-10-07  3:46 ` [PATCH net v4] " Sagi Maimon
2026-10-08 15:47   ` netdev-bot+sashiko
2026-10-11  5:00     ` Sagi Maimon
2026-10-14 18:57   ` Simon Horman [this message]
2026-10-15  7:30   ` patchwork-bot+netdevbpf

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=20261014185716.GD83879@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jacob.e.keller@intel.com \
    --cc=joe@dama.to \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maimon.sagi@gmail.com \
    --cc=michal.simek@amd.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=radhey.shyam.pandey@amd.com \
    --cc=suraj.gupta2@amd.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.