linux-kernel - Re: mmap() implementation for pci_alloc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 24 May 2011 16:18:11 +0200
From:	Leon Woestenberg <leon.woestenberg@...il.com>
To:	Clemens Ladisch <clemens@...isch.de>
Cc:	Takashi Iwai <tiwai@...e.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	linux-pci@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: mmap() implementation for pci_alloc_consistent() memory?

Hello Clemens,

On Mon, May 23, 2011 at 10:30 AM, Clemens Ladisch <clemens@...isch.de> wrote:
> Leon Woestenberg wrote:
>> Having dma_mmap_coherent() there is good for one or two archs, but how
>> can we built portable drivers if the others arch's are still missing?
>
> Easy: Resolve all issues, implement it for all the other arches, and add
> it to the official DMA API.
>
>> How would dma_mmap_coherent() look like on x86?
>
> X86 and some others are always coherent; just use vm_insert_page() or
> remap_page_range().
>
Hello Clemens,

On Mon, May 23, 2011 at 10:30 AM, Clemens Ladisch <clemens@...isch.de> wrote:
> Leon Woestenberg wrote:
>> Having dma_mmap_coherent() there is good for one or two archs, but how
>> can we built portable drivers if the others arch's are still missing?
>
> Easy: Resolve all issues, implement it for all the other arches, and add
> it to the official DMA API.
>
I could send patches, but I would get bashed. Would be a learning
experience though (and a long email thread).

>> How would dma_mmap_coherent() look like on x86?
>
> X86 and some others are always coherent; just use vm_insert_page() or
> remap_page_range().
>

For x86 (my current test system) I tend to go with remap_page_range()
so that the mapping is done before the pages are actually touched.

With that I leave the work-in-progress (dma_mmap_coherent) aside for a
moment, I'll revisit that later on ARM.

However, I still feel I'm treading sandy waters, not familiar enough
with the VM internals.

Does memory allocated with pci_alloc_consistent() need a get_page() in
the driver before I  remap_page_range() it?
Does memory allocated with __get_free_pages() need a get_page() in the
driver before I  remap_page_range() it?

And how about set_bit(PG_reserved, ...) on those pages? Is that
something of the past?

#if 0
...
<vm_insert_page implementation here, disabled>
...
#else /* remap_pfn_range */
#warning Using remap_pfn_range
static int buffer_mmap(struct file *file, struct vm_area_struct *vma)
{
        unsigned long vsize, vsize2;
        void *vaddr, *vaddr2;
        unsigned long start = vma->vm_start;

         * VM_RESERVED: prevent the pages from being swapped out */
        vma->vm_flags |= VM_RESERVED;
        vma->vm_private_data = file->private_data;

        /* allocated using __get_free_pages() or pci_alloc_consistent() */
        vaddr = buffer_virt;
        vsize = buffer_size;

        /* iterate over pages */
        vaddr2 = vaddr;
        vsize2 = vsize;
        while (vsize2 > 0) {
                printk(KERN_DEBUG "get_page(page=%p)\n", virt_to_page(vaddr2));
                get_page(virt_to_page(vaddr2));
                //set_bit(PG_reserved, &(virt_to_page(vaddr2)->flags));
                vaddr2 += PAGE_SIZE;
                vsize2 -= PAGE_SIZE;
        }
        remap_pfn_range(vma, vma->vm_start,
page_to_pfn(virt_to_page(vaddr)), vsize, vma->vm_page_prot);
        return 0;
}
#endif



Thanks for the explanation,

Regards,
-- 
Leon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/