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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 9 Aug 2010 13:11:56 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Leon Woestenberg <leon.woestenberg@...il.com>
Cc:	Tom Lyon <pugs@...co.com>, mst@...hat.com, hjk@...utronix.de,
	gregkh@...e.de, chrisw@...s-sol.org, joro@...tes.org,
	avi@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: UIO DMA to userspace question

On Sat, Aug 07, 2010 at 08:38:30PM +0200, Leon Woestenberg wrote:
> Hello all,
> 
> can I use the UIO framework for the following?
> 
> The userspace portion of the driver allocates memory in user-space
> using malloc() - usually resulting in a scatter pages in physical
> memory.
> The UIO kernel portion of the driver maps those using pci_map_sg().
> 
> Is this possible, or does the UIO framework assume memory for DMA is
> allocated in kernel space?

You would have to write your own mmap() function and and set the pointer
to it in struct uio_info->mmap. Have a look at uio_mmap() in
drivers/uio/uio.c to see when your function will be called, and what is
checked before that call.

If that works, we might invent a new UIO_MEM_* type, and move your function
over to the UIO core, if this is interesting for other people.

Anyway, sooner or later we should have a generic way of handling DMA in
UIO. The topic comes up every few month, but nobody came up with an
acceptable solution yet. It should probably be a separate uio_dma device,
e.g. for a /dev/uio0 you'll get a /dev/uio_dma0 if the driver sets a flag
indicating it needs DMA support. This new uio_dma device should then have
an API (to be defined, without ioctl if possible) that provides the
necessary functionality. But that's just a thought ATM. Ideas/patches are
welcome.

Thanks,
Hans

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ