All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marten Lindahl <martenli@axis.com>
To: Rob Herring <robh@kernel.org>
Cc: "Mårten Lindahl" <Marten.Lindahl@axis.com>,
	"Frank Rowand" <frowand.list@gmail.com>, kernel <kernel@axis.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH] of: dma_configure: Free old DMA map range
Date: Fri, 11 Feb 2022 22:37:45 +0100	[thread overview]
Message-ID: <YgbXKT3SMm+P2LJ6@axis.com> (raw)
In-Reply-To: <YgZ3Ji63vf5FO915@robh.at.kernel.org>

On Fri, Feb 11, 2022 at 03:48:06PM +0100, Rob Herring wrote:
> On Fri, Feb 04, 2022 at 09:45:56AM +0100, Mårten Lindahl wrote:
> > When unbinding/binding a driver with DMA mapped memory, the DMA map is
> > not freed when the driver is reloaded. This leads to a memory leak when
> > the DMA map is overwritten when reprobing the driver.
> > 
> > This can be reproduced with a platform driver having a dma-range:
> > 
> > dummy {
> > 	...
> > 	#address-cells = <0x2>;
> > 	#size-cells = <0x2>;
> > 	ranges;
> > 	dma-ranges = <...>;
> > 	...
> > };
> > 
> > and then unbinding/binding it:
> > 
> > ~# echo soc:dummy >/sys/bus/platform/drivers/<driver>/unbind
> > 
> > DMA map object 0xffffff800b0ae540 still being held by &pdev->dev
> > 
> > ~# echo soc:dummy >/sys/bus/platform/drivers/<driver>/bind
> > ~# echo scan > /sys/kernel/debug/kmemleak
> > ~# cat /sys/kernel/debug/kmemleak
> > unreferenced object 0xffffff800b0ae540 (size 64):
> >   comm "sh", pid 833, jiffies 4295174550 (age 2535.352s)
> >   hex dump (first 32 bytes):
> >     00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >     00 00 00 80 00 00 00 00 00 00 00 80 00 00 00 00  ................
> >   backtrace:
> >     [<ffffffefd1694708>] create_object.isra.0+0x108/0x344
> >     [<ffffffefd1d1a850>] kmemleak_alloc+0x8c/0xd0
> >     [<ffffffefd167e2d0>] __kmalloc+0x440/0x6f0
> >     [<ffffffefd1a960a4>] of_dma_get_range+0x124/0x220
> >     [<ffffffefd1a8ce90>] of_dma_configure_id+0x40/0x2d0
> >     [<ffffffefd198b68c>] platform_dma_configure+0x5c/0xa4
> >     [<ffffffefd198846c>] really_probe+0x8c/0x514
> >     [<ffffffefd1988990>] __driver_probe_device+0x9c/0x19c
> >     [<ffffffefd1988cd8>] device_driver_attach+0x54/0xbc
> >     [<ffffffefd1986634>] bind_store+0xc4/0x120
> >     [<ffffffefd19856e0>] drv_attr_store+0x30/0x44
> >     [<ffffffefd173c9b0>] sysfs_kf_write+0x50/0x60
> >     [<ffffffefd173c1c4>] kernfs_fop_write_iter+0x124/0x1b4
> >     [<ffffffefd16a013c>] new_sync_write+0xdc/0x160
> >     [<ffffffefd16a256c>] vfs_write+0x23c/0x2a0
> >     [<ffffffefd16a2758>] ksys_write+0x64/0xec
> > 
> > Prevent overwriting the dma_range_map by freeing it before saving the
> > new map.
> > 
> > Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
> > ---
> >  drivers/of/device.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index 874f031442dc..a67703d09bfd 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -156,6 +156,12 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
> >  			kfree(map);
> >  			return -EINVAL;
> >  		}
> > +
> > +		/*
> > +		 * Since we are about to set a new range map we should make sure we
> > +		 * do not overwrite any existing one without having freed it first.
> > +		 */
> > +		kfree(dev->dma_range_map);
>
Hi Rob!
Thanks for looking at this.
> 
> The map can't change, can't we just reuse the existing map. Or just bail 
> early? I suppose the driver could have modified the dma masks. Or the 
> IOMMU config could have changed.

Yes, we can reuse the existing map. I will make a check for that instead.

Kind regards
Mårten
> 
> Rob

      reply	other threads:[~2022-02-11 21:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-04  8:45 [PATCH] of: dma_configure: Free old DMA map range Mårten Lindahl
2022-02-11 14:48 ` Rob Herring
2022-02-11 21:37   ` Marten Lindahl [this message]

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=YgbXKT3SMm+P2LJ6@axis.com \
    --to=martenli@axis.com \
    --cc=Marten.Lindahl@axis.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=kernel@axis.com \
    --cc=robh@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.