From: Rob Herring <robh@kernel.org>
To: "Mårten Lindahl" <marten.lindahl@axis.com>
Cc: Frank Rowand <frowand.list@gmail.com>,
kernel@axis.com, devicetree@vger.kernel.org
Subject: Re: [PATCH] of: dma_configure: Free old DMA map range
Date: Fri, 11 Feb 2022 08:48:06 -0600 [thread overview]
Message-ID: <YgZ3Ji63vf5FO915@robh.at.kernel.org> (raw)
In-Reply-To: <20220204084556.3033351-1-marten.lindahl@axis.com>
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);
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.
Rob
next prev parent reply other threads:[~2022-02-11 14:48 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 [this message]
2022-02-11 21:37 ` Marten Lindahl
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=YgZ3Ji63vf5FO915@robh.at.kernel.org \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=kernel@axis.com \
--cc=marten.lindahl@axis.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.