Passing NULL dev to dma_alloc_coherent() allowed or not?

Passing NULL dev to dma_alloc_coherent() allowed or not?

[Richard Weinberger]

Hi!

While porting on an old out-of-tree driver I noticed that dma_alloc_coherent()
was used with dev being NULL.

commit 148a97d5a02a62f81b5d6176f871c94a65e1f3af
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Apr 24 17:24:37 2019 +0300

    dma-mapping: remove an unnecessary NULL check
    
    We already dereferenced "dev" when we called get_dma_ops() so this NULL
    check is too late.  We're not supposed to pass NULL "dev" pointers to
    dma_alloc_attrs().
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>

says that dma_alloc_attrs() with dev being NULL is not allowed, but in
include/linux/dma-mapping.h we have:

static inline void *dma_alloc_coherent(struct device *dev, size_t size,
                dma_addr_t *dma_handle, gfp_t gfp)
{

        return dma_alloc_attrs(dev, size, dma_handle, gfp,
                        (gfp & __GFP_NOWARN) ? DMA_ATTR_NO_WARN : 0);
}

In Linus' tree I see at least three callers of dma_alloc_coherent() with a NULL device.
drivers/staging/emxx_udc/emxx_udc.c:2596:                       ep->virt_buf = dma_alloc_coherent(NULL, PAGE_SIZE,
drivers/tty/synclink.c:3667:            info->buffer_list = dma_alloc_coherent(NULL, BUFFERLISTSIZE, &info->buffer_list_dma_addr, GFP_KERNEL);
drivers/tty/synclink.c:3777:                    BufferList[i].virt_addr = dma_alloc_coherent(NULL, DMABUFFERSIZE, &BufferList[i].dma_addr, GFP_KERNEL);

I think these callers are wrong.
Can you please clarify?

Thanks,
//richard
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: Passing NULL dev to dma_alloc_coherent() allowed or not?

[Dan Carpenter]

On Sat, Jun 27, 2020 at 01:45:16PM +0200, Richard Weinberger wrote:
> Hi!
> 
> While porting on an old out-of-tree driver I noticed that dma_alloc_coherent()
> was used with dev being NULL.
> 
> commit 148a97d5a02a62f81b5d6176f871c94a65e1f3af
> Author: Dan Carpenter <dan.carpenter@oracle.com>
> Date:   Wed Apr 24 17:24:37 2019 +0300
> 
>     dma-mapping: remove an unnecessary NULL check
>     
>     We already dereferenced "dev" when we called get_dma_ops() so this NULL
>     check is too late.  We're not supposed to pass NULL "dev" pointers to
>     dma_alloc_attrs().
>     
>     Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> says that dma_alloc_attrs() with dev being NULL is not allowed, but in
> include/linux/dma-mapping.h we have:
> 
> static inline void *dma_alloc_coherent(struct device *dev, size_t size,
>                 dma_addr_t *dma_handle, gfp_t gfp)
> {
> 
>         return dma_alloc_attrs(dev, size, dma_handle, gfp,
>                         (gfp & __GFP_NOWARN) ? DMA_ATTR_NO_WARN : 0);
> }
> 
> In Linus' tree I see at least three callers of dma_alloc_coherent() with a NULL device.
> drivers/staging/emxx_udc/emxx_udc.c:2596:                       ep->virt_buf = dma_alloc_coherent(NULL, PAGE_SIZE,
> drivers/tty/synclink.c:3667:            info->buffer_list = dma_alloc_coherent(NULL, BUFFERLISTSIZE, &info->buffer_list_dma_addr, GFP_KERNEL);
> drivers/tty/synclink.c:3777:                    BufferList[i].virt_addr = dma_alloc_coherent(NULL, DMABUFFERSIZE, &BufferList[i].dma_addr, GFP_KERNEL);
> 
> I think these callers are wrong.
> Can you please clarify?

The are wrong.  It was slightly worse when I originally sent the patch
but we fixed comedi.


https://lkml.org/lkml/2019/4/24/668

regards,
dan carpenter

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: Passing NULL dev to dma_alloc_coherent() allowed or not?

[Christoph Hellwig]

You can't pass NULL.  The synclink case is dead code as we stopped
supporting non-PCI adapters a while ago.  I had a patch to remove
the !PCI code a while ago, but it seems like it never made it upstream.

The staging code is, well .. staging code.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu