| 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
| ||
|
Date: Tue, 2 Jul 2019 00:06:03 +0530
From: Pankaj Suryawanshi <pankajssuryawanshi@...il.com>
To: Robin Murphy <robin.murphy@....com>
Cc: Christoph Hellwig <hch@...radead.org>, linux-mm@...ck.org,
iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Vlastimil Babka <vbabka@...e.cz>,
Michal Hocko <mhocko@...nel.org>
Subject: Re: DMA-API attr - DMA_ATTR_NO_KERNEL_MAPPING
On Mon, Jul 1, 2019 at 11:17 PM Pankaj Suryawanshi
<pankajssuryawanshi@...il.com> wrote:
>
>
>
>
> On Mon, Jul 1, 2019 at 7:39 PM Robin Murphy <robin.murphy@....com> wrote:
>>
>> On 28/06/2019 17:29, Pankaj Suryawanshi wrote:
>> > On Wed, Jun 26, 2019 at 11:21 PM Christoph Hellwig <hch@...radead.org> 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@...ts.linux-foundation.org. 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.
>
>
> Here is the example that i have tried in my driver.
> ///////////////code snippet/////////////////////////////////////////////////////////////////////////
>
> For CMA allocation using DMA API with DMA_ATTR_NO_KERNEL_MAPPING :-
>
> if(strcmp("video",info->name) == 0)
> {
> printk("Testing CMA Alloc %s\n", info->name);
> info->dma_virt = dma_alloc_attrs(pmap_device, info->size, &phys, GFP_KERNEL,
> DMA_ATTR_WRITE_COMBINE | DMA_ATTR_FORCE_CONTIGUOUS | DMA_ATTR_NO_KERNEL_MAPPING);
> if (!info->dma_virt) {
> pr_err("\x1b[31m" "pmap: cma: failed to alloc %s" "\x1b[0m\n",
> info->name);
> return 0;
> }
> __dma_remap(info->dma_virt, info->size, PAGE_KERNEL); // /*TO DO pgprot we will be taken from attr */ // we will use this only when virtual mapping is required.
> virt = page_address(info->dma_virt); // will use this virtual when kernel mapping needed.
> }
>
> For CMA free using DMA api with DMA_ATTR_NO_KERNEL_MAPPING:-
>
> if(strcmp("video",info->name) == 0)
> {
> printk("Testing CMA Release\n");
> __dma_remap(info->dma_virt, info->size, PAGE_KERNEL);
> dma_free_attrs(pmap_device, info->size, info->dma_virt, phys,
> DMA_ATTR_WRITE_COMBINE | DMA_ATTR_FORCE_CONTIGUOUS | DMA_ATTR_NO_KERNEL_MAPPING);
> }
>
> Flow of Function calls :-
>
> 1. static void *__dma_alloc() // .want_vaddr = ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) == 0)
>
> 2.cma_allocator :-
> i. static void *cma_allocator_alloc ()
> ii. static void *__alloc_from_contiguous() // file name :- ./arch/arm/mm/dma-mapping.c
> if (!want_vaddr)
> goto out; // condition true for DMA_ATTR_NO_KERNEL_MAPPING
>
> if (PageHighMem(page)) {
> ptr = __dma_alloc_remap(page, size, GFP_KERNEL, prot, caller);
> if (!ptr) {
> dma_release_from_contiguous(dev, page, count);
> return NULL;
> }
> } else {
> __dma_remap(page, size, prot);
> ptr = page_address(page);
> }
>
> out:
> *ret_page = page; // return page
> return ptr; // nothing in ptr
> }
> iii. struct page *dma_alloc_from_contiguous()
> iv. cma_alloc()
> 3. dma_alloc () // returns
> return args.want_vaddr ? addr : page; // returns page which is return by alloc_from_contiguous().
>
> What wrong with this if we already know page is returning dma_alloc_attr().
> we can use dma_remap in our driver and free as freed in static void __free_from_contiguous ().
> Please let me know if i missing anything.
>
>> > 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.
>
>
> Do you mean do not use dma-api ? because if i used dma-api it will give you mapped virtual address.
> or i have to use directly cma_alloc() in my driver. // if i used this approach i need to reserved more vmalloc area.
>
> Any help would be appreciated.
>>
>>
>> Robin.
Powered by blists - more mailing lists