Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING

[Robin Murphy]

On 28/06/2019 17:29, Pankaj Suryawanshi wrote:
> On Wed, Jun 26, 2019 at 11:21 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> > On Wed, Jun 26, 2019 at 10:12:45PM +0530, Pankaj Suryawanshi wrote:
> > > [CC: linux kernel and Vlastimil Babka]
> >
> > The right list is the list for the DMA mapping subsystem, which is
> > iommu@xxxxxxxxxxxxxxxxxxxxxxxxxxx  I've also added that.
> >
> > > > I am writing driver in which I used DMA_ATTR_NO_KERNEL_MAPPING attribute
> > > > for cma allocation using dma_alloc_attr(), as per kernel docs
> > > > https://www.kernel.org/doc/Documentation/DMA-attributes.txt  buffers
> > > > allocated with this attribute can be only passed to user space by calling
> > > > dma_mmap_attrs().
> > > >
> > > > how can I mapped in kernel space (after dma_alloc_attr with
> > > > DMA_ATTR_NO_KERNEL_MAPPING ) ?
> >
> > You can't.  And that is the whole point of that API.
>
> 1. We can again mapped in kernel space using dma_remap() api , because
> when we are using  DMA_ATTR_NO_KERNEL_MAPPING for dma_alloc_attr it
> returns the page as virtual address(in case of CMA) so we can mapped
> it again using dma_remap().

No, you really can't. A caller of dma_alloc_attrs(..., 
DMA_ATTR_NO_KERNEL_MAPPING) cannot make any assumptions about the void* 
it returns, other than that it must be handed back to dma_free_attrs() 
later. The implementation is free to ignore the flag and give back a 
virtual mapping anyway. Any driver which depends on how one particular 
implementation on one particular platform happens to behave today is, 
essentially, wrong.

> 2. We can mapped in kernel space using vmap() as used for ion-cma
> https://github.com/torvalds/linux/tree/master/drivers/staging/android/ion
>   as used in function ion_heap_map_kernel().
>
> Please let me know if i am missing anything.

If you want a kernel mapping, *don't* explicitly request not to have a 
kernel mapping in the first place. It's that simple.

Robin.