RE: locking user memory and kiobuf

Bret Indrelee (bindrelee@sbs-cp.com)
Mon, 8 Nov 1999 11:23:46 -0600


Jeff Garzik [mailto:jgarzik@mandrakesoft.com] wrote:
> "Tony E. Bennett" wrote:
> > kiobuf sounds perfect for a problem we have. Currently I
> use mmap() to map
> > pages from __get_free_pages() into user space for dma.
> This is not totally
> > satisfactory, tho, in part because the resulting group of
> pages is not mapped
> > contiguously into kernel.
>
> This is a question I still have unanswered: Does
> map_user_kiobuf indeed
> map the VM into a _contiguous_ region of physical memory?

I don't think so. There is nothing in there I see that would indicate it
does.

It just calls handle_mm_fault() to bring in the necessary pages. See
map_user_kiobuf() in the mm/memory.c source file.

For me, this isn't a problem. I've got scatter/gather DMA capability.

> Note struct kiobuf includes an array of pages which causes some of my
> confusion. Is it legal/possible to do:
>
> /* maps in four pages for read/write access */
> err = map_user_kiobuf (WRITE, iobuf, (ulong) vmaddr,
> PAGE_SIZE * 4);
>
> /* manipulate data in chunks greater than PAGE_SIZE */
> phys = page_address(iobuf->maplist[0]);
> memcpy (foo, phys, PAGE_SIZE * 4);

The pages should be virtually contiguous in user space, so I think something
like this my work.

Does page_address() return a virtual or physical address? To me it looks
like it may be a physical address, in which case you would have to do:
memcpy (foo, phys_to_virt(phys), PAGE_SIZE *4);

-Bret

-------------------------------------------------------------
SBS Technologies, Connectivity Products
... solutions for real-time connectivity

Bret Indrelee, Engineer
SBS Technologies, Inc., Connectivity Products
1284 Corporate Center Drive, St. Paul MN 55121
Direct: (651) 905-4731
Main: (651) 905-4700 Fax: (651) 905-4701
E-mail: bindrelee@sbs-cp.com http://www.sbs.com
-------------------------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/