lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160803193421.GC31688@kroah.com>
Date:	Wed, 3 Aug 2016 21:34:21 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	Vinod Koul <vinod.koul@...el.com>,
	linaro-kernel@...ts.linaro.org, dmaengine@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dmaengine: device must have at least one channel

On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote:
> The DMA device can't be registered if it doesn't have any channels
> registered at all. Moreover, it leads to memory leak and is reported by
> kmemleak as (on 3.10 kernel, and same shall happen on mainline):
> 
> unreferenced object 0xffffffc09e597240 (size 64):
>   comm "swapper/0", pid 1, jiffies 4294877736 (age 7060.280s)
>   hex dump (first 32 bytes):
>     00 00 00 00 c0 ff ff ff 30 00 00 ff 00 00 00 ff  ........0.......
>     00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff  ................
>   backtrace:
>     [<ffffffc0003079ec>] create_object+0x148/0x2a0
>     [<ffffffc000cc150c>] kmemleak_alloc+0x80/0xbc
>     [<ffffffc000303a7c>] kmem_cache_alloc_trace+0x120/0x1ac
>     [<ffffffc00054771c>] dma_async_device_register+0x160/0x46c
>     [<ffffffc000548958>] foo_probe+0x1a0/0x264
>     [<ffffffc0005d6658>] platform_drv_probe+0x14/0x20
>     [<ffffffc0005d50cc>] driver_probe_device+0x160/0x374
>     [<ffffffc0005d538c>] __driver_attach+0x60/0x90
>     [<ffffffc0005d3e78>] bus_for_each_dev+0x7c/0xb0
>     [<ffffffc0005d4a0c>] driver_attach+0x1c/0x28
>     [<ffffffc0005d459c>] bus_add_driver+0x124/0x248
>     [<ffffffc0005d59cc>] driver_register+0x90/0x110
>     [<ffffffc0005d6bf4>] platform_driver_register+0x58/0x64
>     [<ffffffc00142a70c>] foo_driver_init+0x10/0x1c
>     [<ffffffc000200878>] do_one_initcall+0xac/0x148
>     [<ffffffc00140096c>] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> ---
> Hi Vinod,
> 
> Sorry if the fundamentals behind this patch are completely incorrect,
> i.e. We *can't* register a dma device with 0 channels. Its been long
> that I have worked on dma stuff :)
> 
>  drivers/dma/dmaengine.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 8c9f45fd55fc..6b535262ac5d 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -997,6 +997,13 @@ int dma_async_device_register(struct dma_device *device)
>  		}
>  		chan->client_count = 0;
>  	}
> +
> +	if (!chancnt) {
> +		dev_err(device->dev, "%s: device has no channels!\n", __func__);
> +		rc = -ENODEV;
> +		goto err_out;
> +	}
> +
>  	device->chancnt = chancnt;
>  
>  	mutex_lock(&dma_list_mutex);

To follow up on this, as you found out, this patch breaks working
hardware, so please don't apply it anywhere.  It needs more debugging to
figure out exactly what is going on with some very strange hardware that
seems to be relying on some strange code...

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ