All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Frank Li <Frank.li@nxp.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>,
	dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Vinod Koul" <vkoul@kernel.org>, "Frank Li" <Frank.Li@kernel.org>,
	"Eliza Balas" <eliza.balas@analog.com>
Subject: Re: [PATCH v2 4/4] dmaengine: dma-axi-dmac: Defer freeing DMA descriptors
Date: Wed, 1 Apr 2026 17:14:16 +0100	[thread overview]
Message-ID: <ac1C8VdYXe3pMu0B@nsa> (raw)
In-Reply-To: <acvmNkDwLsdJCvWa@nsa>

On Tue, Mar 31, 2026 at 04:21:06PM +0100, Nuno Sá wrote:
> On Tue, Mar 31, 2026 at 10:16:09AM -0400, Frank Li wrote:
> > On Tue, Mar 31, 2026 at 09:53:45AM +0100, Nuno Sá wrote:
> > > On Mon, Mar 30, 2026 at 11:24:34AM -0400, Frank Li wrote:
> > > > On Fri, Mar 27, 2026 at 04:58:41PM +0000, Nuno Sá wrote:
> > > > > From: Eliza Balas <eliza.balas@analog.com>
> > > > >
> > > > > This IP core can be used in architectures (like Microblaze) where DMA
> > > > > descriptors are allocated with vmalloc().
> > > >
> > > > strage, why use vmalloc()?
> > >
> > > It's just one of the paths in dma_alloc_coherent(). It should be
> > > architecture dependant.
> > 
> > Which architectures, this may common problem, dma_alloc/free_coherent() is
> > quite common at other dma-engine driver.
> 
> I'll double check this but I believe this was triggered on microblaze
> where we also use this IP. Will come back with confirmation!
> 

Hi Frank,

I now went to the bottom of the issue! The problem is that for archs
like microblaze and arm64 we have DMA_DIRECT_REMAP which means that when
calling dma_alloc_coherent() in [1] we will get into the code path in
[2]. Now I did some research and we might have other solution for this
that does not involve this refcount craziness plus async work. But I
need to test it. FYI, what I have in mind is similar to the what 
loongson2-apb-dma.c does. This means, using the dma pool API. IIUC, with
the pool we only actually free the memory (dma_free_coherent()) in the
.terminate_all() callback (when destroying the pool) which should not
happen in interrupt context right?

[1]: https://elixir.bootlin.com/linux/v7.0-rc6/source/drivers/dma/dma-axi-dmac.c#L549
[2]: https://elixir.bootlin.com/linux/v7.0-rc6/source/kernel/dma/direct.c#L278

- Nuno Sá

> - Nuno Sá
> > 
> > Frank
> > 
> > >
> > > - Nuno Sá
> > >
> > > >
> > > > Frank
> > > >
> > > > >  Hence, given that freeing the
> > > > > descriptors happen in softirq context, vunmpap() will BUG().
> > > > >
> > > > > To solve the above, we setup a work item during allocation of the
> > > > > descriptors and schedule in softirq context. Hence, the actual freeing
> > > > > happens in threaded context.
> > > > >
> > > > > Also note that to account for the possible race where the struct axi_dmac
> > > > > object is gone between scheduling the work and actually running it, we
> > > > > now save and get a reference of struct device when allocating the
> > > > > descriptor (given that's all we need in axi_dmac_free_desc()) and
> > > > > release it in axi_dmac_free_desc().
> > > > >
> > > > > Signed-off-by: Eliza Balas <eliza.balas@analog.com>
> > > > > Co-developed-by: Nuno Sá <nuno.sa@analog.com>
> > > > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > > > ---
> > > > >  drivers/dma/dma-axi-dmac.c | 50 ++++++++++++++++++++++++++++++++++------------
> > > > >  1 file changed, 37 insertions(+), 13 deletions(-)
> > > > >
> > > > > diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
> > > > > index 70d3ad7e7d37..46f1ead0c7d7 100644
> > > > > --- a/drivers/dma/dma-axi-dmac.c
> > > > > +++ b/drivers/dma/dma-axi-dmac.c
> > > > > @@ -25,6 +25,7 @@
> > > > >  #include <linux/regmap.h>
> > > > >  #include <linux/slab.h>
> > > > >  #include <linux/spinlock.h>
> > > > > +#include <linux/workqueue.h>
> > > > >
> > > > >  #include <dt-bindings/dma/axi-dmac.h>
> > > > >
> > > > > @@ -133,6 +134,9 @@ struct axi_dmac_sg {
> > > > >  struct axi_dmac_desc {
> > > > >  	struct virt_dma_desc vdesc;
> > > > >  	struct axi_dmac_chan *chan;
> > > > > +	struct device *dev;
> > > > > +
> > > > > +	struct work_struct sched_work;
> > > > >
> > > > >  	bool cyclic;
> > > > >  	bool cyclic_eot;
> > > > > @@ -666,6 +670,25 @@ static void axi_dmac_issue_pending(struct dma_chan *c)
> > > > >  	spin_unlock_irqrestore(&chan->vchan.lock, flags);
> > > > >  }
> > > > >
> > > > > +static void axi_dmac_free_desc(struct axi_dmac_desc *desc)
> > > > > +{
> > > > > +	struct axi_dmac_hw_desc *hw = desc->sg[0].hw;
> > > > > +	dma_addr_t hw_phys = desc->sg[0].hw_phys;
> > > > > +
> > > > > +	dma_free_coherent(desc->dev, PAGE_ALIGN(desc->num_sgs * sizeof(*hw)),
> > > > > +			  hw, hw_phys);
> > > > > +	put_device(desc->dev);
> > > > > +	kfree(desc);
> > > > > +}
> > > > > +
> > > > > +static void axi_dmac_free_desc_schedule_work(struct work_struct *work)
> > > > > +{
> > > > > +	struct axi_dmac_desc *desc = container_of(work, struct axi_dmac_desc,
> > > > > +						  sched_work);
> > > > > +
> > > > > +	axi_dmac_free_desc(desc);
> > > > > +}
> > > > > +
> > > > >  static struct axi_dmac_desc *
> > > > >  axi_dmac_alloc_desc(struct axi_dmac_chan *chan, unsigned int num_sgs)
> > > > >  {
> > > > > @@ -681,6 +704,7 @@ axi_dmac_alloc_desc(struct axi_dmac_chan *chan, unsigned int num_sgs)
> > > > >  		return NULL;
> > > > >  	desc->num_sgs = num_sgs;
> > > > >  	desc->chan = chan;
> > > > > +	desc->dev = get_device(dmac->dma_dev.dev);
> > > > >
> > > > >  	hws = dma_alloc_coherent(dev, PAGE_ALIGN(num_sgs * sizeof(*hws)),
> > > > >  				&hw_phys, GFP_ATOMIC);
> > > > > @@ -703,21 +727,18 @@ axi_dmac_alloc_desc(struct axi_dmac_chan *chan, unsigned int num_sgs)
> > > > >  	/* The last hardware descriptor will trigger an interrupt */
> > > > >  	desc->sg[num_sgs - 1].hw->flags = AXI_DMAC_HW_FLAG_LAST | AXI_DMAC_HW_FLAG_IRQ;
> > > > >
> > > > > +	/*
> > > > > +	 * We need to setup a work item because this IP can be used on archs
> > > > > +	 * that rely on vmalloced memory for descriptors. And given that freeing
> > > > > +	 * the descriptors happens in softirq context, vunmpap() will BUG().
> > > > > +	 * Hence, setup the worker so that we can queue it and free the
> > > > > +	 * descriptor in threaded context.
> > > > > +	 */
> > > > > +	INIT_WORK(&desc->sched_work, axi_dmac_free_desc_schedule_work);
> > > > > +
> > > > >  	return desc;
> > > > >  }
> > > > >
> > > > > -static void axi_dmac_free_desc(struct axi_dmac_desc *desc)
> > > > > -{
> > > > > -	struct axi_dmac *dmac = chan_to_axi_dmac(desc->chan);
> > > > > -	struct device *dev = dmac->dma_dev.dev;
> > > > > -	struct axi_dmac_hw_desc *hw = desc->sg[0].hw;
> > > > > -	dma_addr_t hw_phys = desc->sg[0].hw_phys;
> > > > > -
> > > > > -	dma_free_coherent(dev, PAGE_ALIGN(desc->num_sgs * sizeof(*hw)),
> > > > > -			  hw, hw_phys);
> > > > > -	kfree(desc);
> > > > > -}
> > > > > -
> > > > >  static struct axi_dmac_sg *axi_dmac_fill_linear_sg(struct axi_dmac_chan *chan,
> > > > >  	enum dma_transfer_direction direction, dma_addr_t addr,
> > > > >  	unsigned int num_periods, unsigned int period_len,
> > > > > @@ -958,7 +979,10 @@ static void axi_dmac_free_chan_resources(struct dma_chan *c)
> > > > >
> > > > >  static void axi_dmac_desc_free(struct virt_dma_desc *vdesc)
> > > > >  {
> > > > > -	axi_dmac_free_desc(to_axi_dmac_desc(vdesc));
> > > > > +	struct axi_dmac_desc *desc = to_axi_dmac_desc(vdesc);
> > > > > +
> > > > > +	/* See the comment in axi_dmac_alloc_desc() for the why! */
> > > > > +	schedule_work(&desc->sched_work);
> > > > >  }
> > > > >
> > > > >  static bool axi_dmac_regmap_rdwr(struct device *dev, unsigned int reg)
> > > > >
> > > > > --
> > > > > 2.53.0
> > > > >

  reply	other threads:[~2026-04-01 16:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-27 16:58 [PATCH v2 0/4] dmaengine: dma-axi-dmac: Some memory related fixes Nuno Sá
2026-03-27 16:58 ` Nuno Sá via B4 Relay
2026-03-27 16:58 ` [PATCH v2 1/4] dmaengine: Fix possuible use after free Nuno Sá
2026-03-27 16:58   ` Nuno Sá via B4 Relay
2026-03-30 15:15   ` Frank Li
2026-03-27 16:58 ` [PATCH v2 2/4] dmaengine: dma-axi-dmac: Properly free struct axi_dmac_desc Nuno Sá
2026-03-27 16:58   ` Nuno Sá via B4 Relay
2026-03-30 15:17   ` Frank Li
2026-03-27 16:58 ` [PATCH v2 3/4] dmaengine: dma-axi-dmac: fix use-after-free on unbind Nuno Sá
2026-03-27 16:58   ` Nuno Sá via B4 Relay
2026-03-30 15:22   ` Frank Li
2026-03-31  8:46     ` Nuno Sá
2026-03-31 14:20       ` Frank Li
2026-03-27 16:58 ` [PATCH v2 4/4] dmaengine: dma-axi-dmac: Defer freeing DMA descriptors Nuno Sá
2026-03-27 16:58   ` Nuno Sá via B4 Relay
2026-03-30 15:24   ` Frank Li
2026-03-31  8:53     ` Nuno Sá
2026-03-31 14:16       ` Frank Li
2026-03-31 15:21         ` Nuno Sá
2026-04-01 16:14           ` Nuno Sá [this message]
2026-04-01 22:27             ` Frank Li
2026-04-02 17:06               ` Nuno Sá

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=ac1C8VdYXe3pMu0B@nsa \
    --to=noname.nuno@gmail.com \
    --cc=Frank.Li@kernel.org \
    --cc=Frank.li@nxp.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=eliza.balas@analog.com \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=vkoul@kernel.org \
    /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.