lkml.org 
[lkml]   [2020]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] device core: fix dma_mask handling in platform_device_register_full
From
Date
On 3/11/20 4:07 PM, Christoph Hellwig wrote:
> Ever since the generic platform device code started allocating DMA masks
> itself the code to allocate and leak a private DMA mask in
> platform_device_register_full has been superflous. More so the fact that
> it unconditionally frees the DMA mask allocation in the failure path
> can lead to slab corruption if the function fails later on for a device
> where it didn't allocate the mask. Just remove the offending code.
>
> Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device")
> Reported-by: Artem S. Tashkinov <aros@gmx.com>
> Tested-by: Artem S. Tashkinov <aros@gmx.com>
> ---
> drivers/base/platform.c | 14 --------------
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 7fa654f1288b..47d3e6187a1c 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -662,19 +662,6 @@ struct platform_device *platform_device_register_full(
> pdev->dev.of_node_reused = pdevinfo->of_node_reused;
>
> if (pdevinfo->dma_mask) {
> - /*
> - * This memory isn't freed when the device is put,
> - * I don't have a nice idea for that though. Conceptually
> - * dma_mask in struct device should not be a pointer.
> - * See http://thread.gmane.org/gmane.linux.kernel.pci/9081
> - */
> - pdev->dev.dma_mask =
> - kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
> - if (!pdev->dev.dma_mask)
> - goto err;
> -
> - kmemleak_ignore(pdev->dev.dma_mask);
> -
> *pdev->dev.dma_mask = pdevinfo->dma_mask;
> pdev->dev.coherent_dma_mask = pdevinfo->dma_mask;
> }
> @@ -700,7 +687,6 @@ struct platform_device *platform_device_register_full(
> if (ret) {
> err:
> ACPI_COMPANION_SET(&pdev->dev, NULL);
> - kfree(pdev->dev.dma_mask);
> platform_device_put(pdev);
> return ERR_PTR(ret);
> }
>

I'd love to see this patch applied to the next round of stable kernels
(at the very least 5.5.x) ASAP because I've been stuck with kernel 5.3
on Fedora for quite some time already.

Thank you!

\
 
 \ /
  Last update: 2020-03-11 17:11    [W:0.059 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site