Re: [PATCH] dmaengine: device must have at least one channel

[Vinod Koul]

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 0xffc09e597240 (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:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: device must have at least one channel

[Vinod Koul]

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 0xffc09e597240 (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:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 08-08-16, 19:06, Greg Kroah-Hartman wrote:
> So only the drivers that are out-of-tree are broken with this patch?
> 
> I like it :)

I know that and I like it too :)

But yeah its only the *hacky* out of tree drivers are going to be broken with
this.

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 08-08-16, 19:06, Greg Kroah-Hartman wrote:
> So only the drivers that are out-of-tree are broken with this patch?
> 
> I like it :)

I know that and I like it too :)

But yeah its only the *hacky* out of tree drivers are going to be broken with
this.

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Greg Kroah-Hartman]

On Mon, Aug 08, 2016 at 08:24:49AM -0700, Viresh Kumar wrote:
> On 08-08-16, 13:47, Vinod Koul wrote:
> > On Fri, Aug 05, 2016 at 09:30:50AM -0700, Viresh Kumar wrote:
> > > On 03-08-16, 21:34, Greg Kroah-Hartman wrote:
> > 
> > > > 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 for your email Greg, and I know what the issue is.
> > > 
> > > So, the dmaengine core actually allows registering a device without any 
> > > channels
> > > and the dma driver can add channels later (directly to the dma-device 
> > > channel
> > > list), for example, from the of-xlate callback once someone requests for a
> > > channel.
> > 
> > I do not think that is good idea
> > 
> > > Though its not the right way of doing things, but it still works. The 
> > > only thing
> > > which breaks in that case is sysfs interface to dmaengine as the channels 
> > > aren't
> > > registered as devices and so they aren't visible in userspace, as that 
> > > code is
> > > *only* executed while the dma-device is registered.
> > > 
> > > I think its dmaengine core's decision to keep supporting such drivers or 
> > > not and
> > > so I would like Vinod to comment on that..
> > 
> > My view would be to ensure that controllers have channels before they
> > register. If they dont, then please register later.
> > 
> > > But if we do want to support such drivers, then the core must be updated 
> > > to fix
> > > the memleak I reported here, as idr_ref is allocated and not used at all 
> > > (also
> > > dma-id allocated for it).
> > > 
> > > Or provide another API to properly and fully add channels at a later 
> > > point of
> > > time.
> > 
> > And looking at drivers, I am not seeing anyone who needs such a support, so
> > am not inclined to support such a feature atm.
> 
> Right and so I believe that applying this patch is the right thing to do..

So only the drivers that are out-of-tree are broken with this patch?

I like it :)

greg k-h

Re: [PATCH] dmaengine: device must have at least one channel

[Greg Kroah-Hartman]

On Mon, Aug 08, 2016 at 08:24:49AM -0700, Viresh Kumar wrote:
> On 08-08-16, 13:47, Vinod Koul wrote:
> > On Fri, Aug 05, 2016 at 09:30:50AM -0700, Viresh Kumar wrote:
> > > On 03-08-16, 21:34, Greg Kroah-Hartman wrote:
> > 
> > > > 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 for your email Greg, and I know what the issue is.
> > > 
> > > So, the dmaengine core actually allows registering a device without any 
> > > channels
> > > and the dma driver can add channels later (directly to the dma-device 
> > > channel
> > > list), for example, from the of-xlate callback once someone requests for a
> > > channel.
> > 
> > I do not think that is good idea
> > 
> > > Though its not the right way of doing things, but it still works. The 
> > > only thing
> > > which breaks in that case is sysfs interface to dmaengine as the channels 
> > > aren't
> > > registered as devices and so they aren't visible in userspace, as that 
> > > code is
> > > *only* executed while the dma-device is registered.
> > > 
> > > I think its dmaengine core's decision to keep supporting such drivers or 
> > > not and
> > > so I would like Vinod to comment on that..
> > 
> > My view would be to ensure that controllers have channels before they
> > register. If they dont, then please register later.
> > 
> > > But if we do want to support such drivers, then the core must be updated 
> > > to fix
> > > the memleak I reported here, as idr_ref is allocated and not used at all 
> > > (also
> > > dma-id allocated for it).
> > > 
> > > Or provide another API to properly and fully add channels at a later 
> > > point of
> > > time.
> > 
> > And looking at drivers, I am not seeing anyone who needs such a support, so
> > am not inclined to support such a feature atm.
> 
> Right and so I believe that applying this patch is the right thing to do..

So only the drivers that are out-of-tree are broken with this patch?

I like it :)

greg k-h

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 08-08-16, 13:47, Vinod Koul wrote:
> On Fri, Aug 05, 2016 at 09:30:50AM -0700, Viresh Kumar wrote:
> > On 03-08-16, 21:34, Greg Kroah-Hartman wrote:
> 
> > > 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 for your email Greg, and I know what the issue is.
> > 
> > So, the dmaengine core actually allows registering a device without any 
> > channels
> > and the dma driver can add channels later (directly to the dma-device 
> > channel
> > list), for example, from the of-xlate callback once someone requests for a
> > channel.
> 
> I do not think that is good idea
> 
> > Though its not the right way of doing things, but it still works. The only 
> > thing
> > which breaks in that case is sysfs interface to dmaengine as the channels 
> > aren't
> > registered as devices and so they aren't visible in userspace, as that code 
> > is
> > *only* executed while the dma-device is registered.
> > 
> > I think its dmaengine core's decision to keep supporting such drivers or 
> > not and
> > so I would like Vinod to comment on that..
> 
> My view would be to ensure that controllers have channels before they
> register. If they dont, then please register later.
> 
> > But if we do want to support such drivers, then the core must be updated to 
> > fix
> > the memleak I reported here, as idr_ref is allocated and not used at all 
> > (also
> > dma-id allocated for it).
> > 
> > Or provide another API to properly and fully add channels at a later point 
> > of
> > time.
> 
> And looking at drivers, I am not seeing anyone who needs such a support, so
> am not inclined to support such a feature atm.

Right and so I believe that applying this patch is the right thing to do..

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 08-08-16, 13:47, Vinod Koul wrote:
> On Fri, Aug 05, 2016 at 09:30:50AM -0700, Viresh Kumar wrote:
> > On 03-08-16, 21:34, Greg Kroah-Hartman wrote:
> 
> > > 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 for your email Greg, and I know what the issue is.
> > 
> > So, the dmaengine core actually allows registering a device without any 
> > channels
> > and the dma driver can add channels later (directly to the dma-device 
> > channel
> > list), for example, from the of-xlate callback once someone requests for a
> > channel.
> 
> I do not think that is good idea
> 
> > Though its not the right way of doing things, but it still works. The only 
> > thing
> > which breaks in that case is sysfs interface to dmaengine as the channels 
> > aren't
> > registered as devices and so they aren't visible in userspace, as that code 
> > is
> > *only* executed while the dma-device is registered.
> > 
> > I think its dmaengine core's decision to keep supporting such drivers or 
> > not and
> > so I would like Vinod to comment on that..
> 
> My view would be to ensure that controllers have channels before they
> register. If they dont, then please register later.
> 
> > But if we do want to support such drivers, then the core must be updated to 
> > fix
> > the memleak I reported here, as idr_ref is allocated and not used at all 
> > (also
> > dma-id allocated for it).
> > 
> > Or provide another API to properly and fully add channels at a later point 
> > of
> > time.
> 
> And looking at drivers, I am not seeing anyone who needs such a support, so
> am not inclined to support such a feature atm.

Right and so I believe that applying this patch is the right thing to do..

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Vinod Koul]

On Fri, Aug 05, 2016 at 09:30:50AM -0700, Viresh Kumar wrote:
> On 03-08-16, 21:34, Greg Kroah-Hartman wrote:

> > 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 for your email Greg, and I know what the issue is.
> 
> So, the dmaengine core actually allows registering a device without any 
> channels
> and the dma driver can add channels later (directly to the dma-device channel
> list), for example, from the of-xlate callback once someone requests for a
> channel.

I do not think that is good idea

> Though its not the right way of doing things, but it still works. The only 
> thing
> which breaks in that case is sysfs interface to dmaengine as the channels 
> aren't
> registered as devices and so they aren't visible in userspace, as that code is
> *only* executed while the dma-device is registered.
> 
> I think its dmaengine core's decision to keep supporting such drivers or not 
> and
> so I would like Vinod to comment on that..

My view would be to ensure that controllers have channels before they
register. If they dont, then please register later.

> But if we do want to support such drivers, then the core must be updated to 
> fix
> the memleak I reported here, as idr_ref is allocated and not used at all (also
> dma-id allocated for it).
> 
> Or provide another API to properly and fully add channels at a later point of
> time.

And looking at drivers, I am not seeing anyone who needs such a support, so
am not inclined to support such a feature atm.

-- 
~Vinod

Re: [PATCH] dmaengine: device must have at least one channel

[Vinod Koul]

On Fri, Aug 05, 2016 at 09:30:50AM -0700, Viresh Kumar wrote:
> On 03-08-16, 21:34, Greg Kroah-Hartman wrote:

> > 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 for your email Greg, and I know what the issue is.
> 
> So, the dmaengine core actually allows registering a device without any 
> channels
> and the dma driver can add channels later (directly to the dma-device channel
> list), for example, from the of-xlate callback once someone requests for a
> channel.

I do not think that is good idea

> Though its not the right way of doing things, but it still works. The only 
> thing
> which breaks in that case is sysfs interface to dmaengine as the channels 
> aren't
> registered as devices and so they aren't visible in userspace, as that code is
> *only* executed while the dma-device is registered.
> 
> I think its dmaengine core's decision to keep supporting such drivers or not 
> and
> so I would like Vinod to comment on that..

My view would be to ensure that controllers have channels before they
register. If they dont, then please register later.

> But if we do want to support such drivers, then the core must be updated to 
> fix
> the memleak I reported here, as idr_ref is allocated and not used at all (also
> dma-id allocated for it).
> 
> Or provide another API to properly and fully add channels at a later point of
> time.

And looking at drivers, I am not seeing anyone who needs such a support, so
am not inclined to support such a feature atm.

-- 
~Vinod

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 03-08-16, 21:34, Greg Kroah-Hartman wrote:
> 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 0xffc09e597240 (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:
> > [] create_object+0x148/0x2a0
> > [] kmemleak_alloc+0x80/0xbc
> > [] kmem_cache_alloc_trace+0x120/0x1ac
> > [] dma_async_device_register+0x160/0x46c
> > [] foo_probe+0x1a0/0x264
> > [] platform_drv_probe+0x14/0x20
> > [] driver_probe_device+0x160/0x374
> > [] __driver_attach+0x60/0x90
> > [] bus_for_each_dev+0x7c/0xb0
> > [] driver_attach+0x1c/0x28
> > [] bus_add_driver+0x124/0x248
> > [] driver_register+0x90/0x110
> > [] platform_driver_register+0x58/0x64
> > [] foo_driver_init+0x10/0x1c
> > [] do_one_initcall+0xac/0x148
> > [] kernel_init_freeable+0x1a0/0x258
> > 
> > Return -ENODEV from dma_async_device_register() on such a case.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> > 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(_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 for your email Greg, and I know what the issue is.

So, the dmaengine core actually allows registering a device without any channels
and the dma driver can add channels later (directly to the dma-device channel
list), for example, from the of-xlate callback once someone requests for a
channel.

Though its not the right way of doing things, but it still works. The only thing
which breaks in that case is sysfs interface to dmaengine as the channels aren't
registered as devices and so they aren't visible in userspace, as that code is
*only* executed while the dma-device is registered.

I think its dmaengine core's decision to keep supporting such drivers or not and
so I would like Vinod to comment on that..

But if we do want to support such drivers, then the core must be updated to fix
the memleak I reported here, as idr_ref is allocated and not used at all (also
dma-id allocated for it).

Or provide another API to properly and fully add channels at a later point of
time.

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 03-08-16, 21:34, Greg Kroah-Hartman wrote:
> 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 0xffc09e597240 (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:
> > [] create_object+0x148/0x2a0
> > [] kmemleak_alloc+0x80/0xbc
> > [] kmem_cache_alloc_trace+0x120/0x1ac
> > [] dma_async_device_register+0x160/0x46c
> > [] foo_probe+0x1a0/0x264
> > [] platform_drv_probe+0x14/0x20
> > [] driver_probe_device+0x160/0x374
> > [] __driver_attach+0x60/0x90
> > [] bus_for_each_dev+0x7c/0xb0
> > [] driver_attach+0x1c/0x28
> > [] bus_add_driver+0x124/0x248
> > [] driver_register+0x90/0x110
> > [] platform_driver_register+0x58/0x64
> > [] foo_driver_init+0x10/0x1c
> > [] do_one_initcall+0xac/0x148
> > [] kernel_init_freeable+0x1a0/0x258
> > 
> > Return -ENODEV from dma_async_device_register() on such a case.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> > 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(_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 for your email Greg, and I know what the issue is.

So, the dmaengine core actually allows registering a device without any channels
and the dma driver can add channels later (directly to the dma-device channel
list), for example, from the of-xlate callback once someone requests for a
channel.

Though its not the right way of doing things, but it still works. The only thing
which breaks in that case is sysfs interface to dmaengine as the channels aren't
registered as devices and so they aren't visible in userspace, as that code is
*only* executed while the dma-device is registered.

I think its dmaengine core's decision to keep supporting such drivers or not and
so I would like Vinod to comment on that..

But if we do want to support such drivers, then the core must be updated to fix
the memleak I reported here, as idr_ref is allocated and not used at all (also
dma-id allocated for it).

Or provide another API to properly and fully add channels at a later point of
time.

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Greg Kroah-Hartman]

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 0xffc09e597240 (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:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.
> 
> Signed-off-by: Viresh Kumar 
> ---
> 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(_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

Re: [PATCH] dmaengine: device must have at least one channel

[Greg Kroah-Hartman]

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 0xffc09e597240 (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:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.
> 
> Signed-off-by: Viresh Kumar 
> ---
> 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(_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

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 28-07-16, 09:18, Vinod Koul wrote:
> 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 0xffc09e597240 (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:
> > [] create_object+0x148/0x2a0
> > [] kmemleak_alloc+0x80/0xbc
> > [] kmem_cache_alloc_trace+0x120/0x1ac
> > [] dma_async_device_register+0x160/0x46c
> > [] foo_probe+0x1a0/0x264
> > [] platform_drv_probe+0x14/0x20
> > [] driver_probe_device+0x160/0x374
> > [] __driver_attach+0x60/0x90
> > [] bus_for_each_dev+0x7c/0xb0
> > [] driver_attach+0x1c/0x28
> > [] bus_add_driver+0x124/0x248
> > [] driver_register+0x90/0x110
> > [] platform_driver_register+0x58/0x64
> > [] foo_driver_init+0x10/0x1c
> > [] do_one_initcall+0xac/0x148
> > [] kernel_init_freeable+0x1a0/0x258
> > 
> > Return -ENODEV from dma_async_device_register() on such a case.
> > 
> > /Signed-off-by: Viresh Kumar 
> > ---
> > 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 :)
> 
> This sounds okay,

Great..

> but why would anyone register a device without having
> a channel?

A buggy driver? The core should be handling this no matter what,
right?

The out of tree driver, 3.10 based driver I have looks to be buggy to
me. It is doing something like this (please ignore naming/formatting):

xlate()
{
chan = alloc();
list_add(chan.device_node, _dev.channels)
}

probe()
{
...
dma_async_device_register()
of_dma_controller_register(xlate);
...
}

But with this it looks like the 'chan' structure wouldn't get
initialized properly as that is done from within
dma_async_device_register(). Right? Also, I am not sure if DMA is
getting used at all right now on my platform. Just noticed the
memleak, which I tried to fix.

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

On 28-07-16, 09:18, Vinod Koul wrote:
> 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 0xffc09e597240 (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:
> > [] create_object+0x148/0x2a0
> > [] kmemleak_alloc+0x80/0xbc
> > [] kmem_cache_alloc_trace+0x120/0x1ac
> > [] dma_async_device_register+0x160/0x46c
> > [] foo_probe+0x1a0/0x264
> > [] platform_drv_probe+0x14/0x20
> > [] driver_probe_device+0x160/0x374
> > [] __driver_attach+0x60/0x90
> > [] bus_for_each_dev+0x7c/0xb0
> > [] driver_attach+0x1c/0x28
> > [] bus_add_driver+0x124/0x248
> > [] driver_register+0x90/0x110
> > [] platform_driver_register+0x58/0x64
> > [] foo_driver_init+0x10/0x1c
> > [] do_one_initcall+0xac/0x148
> > [] kernel_init_freeable+0x1a0/0x258
> > 
> > Return -ENODEV from dma_async_device_register() on such a case.
> > 
> > /Signed-off-by: Viresh Kumar 
> > ---
> > 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 :)
> 
> This sounds okay,

Great..

> but why would anyone register a device without having
> a channel?

A buggy driver? The core should be handling this no matter what,
right?

The out of tree driver, 3.10 based driver I have looks to be buggy to
me. It is doing something like this (please ignore naming/formatting):

xlate()
{
chan = alloc();
list_add(chan.device_node, _dev.channels)
}

probe()
{
...
dma_async_device_register()
of_dma_controller_register(xlate);
...
}

But with this it looks like the 'chan' structure wouldn't get
initialized properly as that is done from within
dma_async_device_register(). Right? Also, I am not sure if DMA is
getting used at all right now on my platform. Just noticed the
memleak, which I tried to fix.

-- 
viresh

Re: [PATCH] dmaengine: device must have at least one channel

[Vinod Koul]

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 0xffc09e597240 (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:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.
> 
> Signed-off-by: Viresh Kumar 
> ---
> 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 :)

This sounds okay, but why would anyone register a device without having
a channel?

> 
>  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(_list_mutex);
> -- 
> 2.7.4
> 

-- 
~Vinod

Re: [PATCH] dmaengine: device must have at least one channel

[Vinod Koul]

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 0xffc09e597240 (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:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.
> 
> Signed-off-by: Viresh Kumar 
> ---
> 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 :)

This sounds okay, but why would anyone register a device without having
a channel?

> 
>  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(_list_mutex);
> -- 
> 2.7.4
> 

-- 
~Vinod

[PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

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 0xffc09e597240 (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:
[] create_object+0x148/0x2a0
[] kmemleak_alloc+0x80/0xbc
[] kmem_cache_alloc_trace+0x120/0x1ac
[] dma_async_device_register+0x160/0x46c
[] foo_probe+0x1a0/0x264
[] platform_drv_probe+0x14/0x20
[] driver_probe_device+0x160/0x374
[] __driver_attach+0x60/0x90
[] bus_for_each_dev+0x7c/0xb0
[] driver_attach+0x1c/0x28
[] bus_add_driver+0x124/0x248
[] driver_register+0x90/0x110
[] platform_driver_register+0x58/0x64
[] foo_driver_init+0x10/0x1c
[] do_one_initcall+0xac/0x148
[] kernel_init_freeable+0x1a0/0x258

Return -ENODEV from dma_async_device_register() on such a case.

Signed-off-by: Viresh Kumar 
---
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(_list_mutex);
-- 
2.7.4

[PATCH] dmaengine: device must have at least one channel

[Viresh Kumar]

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 0xffc09e597240 (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:
[] create_object+0x148/0x2a0
[] kmemleak_alloc+0x80/0xbc
[] kmem_cache_alloc_trace+0x120/0x1ac
[] dma_async_device_register+0x160/0x46c
[] foo_probe+0x1a0/0x264
[] platform_drv_probe+0x14/0x20
[] driver_probe_device+0x160/0x374
[] __driver_attach+0x60/0x90
[] bus_for_each_dev+0x7c/0xb0
[] driver_attach+0x1c/0x28
[] bus_add_driver+0x124/0x248
[] driver_register+0x90/0x110
[] platform_driver_register+0x58/0x64
[] foo_driver_init+0x10/0x1c
[] do_one_initcall+0xac/0x148
[] kernel_init_freeable+0x1a0/0x258

Return -ENODEV from dma_async_device_register() on such a case.

Signed-off-by: Viresh Kumar 
---
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(_list_mutex);
-- 
2.7.4