linux-kernel - Re: [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA

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]

Message-ID: <20091216012347.GD2432@local>
Date:	Wed, 16 Dec 2009 02:23:49 +0100
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Earl Chew <earl_chew@...lent.com>
Cc:	"Hans J. Koch" <hjk@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, gregkh@...e.de,
	linux-mm <linux-mm@...ck.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/1] Userspace I/O (UIO): Add support for userspace DMA

On Tue, Dec 15, 2009 at 04:20:56PM -0800, Earl Chew wrote:
> Hans J. Koch wrote:
> > One example: An A/D converter has an on-chip 32k buffer. It causes an
> > interrupt as soon as the buffer is filled up to a certain high-water mark.
> > Such cases would easily fit into the current UIO system. The UIO core could
> > simply DMA the data to one of the mappings. A new flag for that mapping and
> > a few other changes are all it takes. After the DMA transfer is complete, the
> > interrupt is passed on to userspace, which would find the buffer already
> > filled with the desired data. Just a thought, unfortunately I haven't got
> > such hardware to try it.
> 
> Hans,
> 
> Is this case already covered by the pre-existing UIO_MEM_LOGICAL
> option ?
> 
> I'm thinking that since the memory is statically defined, it can be
> described using one of the existing struct uio_mem mem[] slots in
> struct uio_info and marked as UIO_MEM_LOGICAL.
> 
> The userspace program can map that into its process space using the
> existing mmap() interface.
> 
> What am I missing?

Nothing. The UIO core can map all kinds of memory. I thought about a generic
DMA routine that does the transfer if a flag like UIO_DMA_FROM_DEVICE_PRE_USER
is set.

> 
> > When it comes to dynamically allocated DMA buffers, it might well be possible
> > to add a new directory in sysfs besides the "mem" directory, e.g. something
> > like /sys/class/uio/uioN/dma-mem/. This would save us the trouble of creating
> > a new device. Maybe the example above would better fit in here, too. Who knows.
> 
> I looked at the 2.6.32 source at
> 
> http://lxr.linux.no/#linux+v2.6.32/drivers/uio/uio.c
> 
> and didn't see any reference to /sys/class/uio/uioN/mem .  Perhaps
> you're referring to something new.

Just look at the sysfs files you get when creating a UIO device, then look at
uio.c to see how it is done.

> 
> In any case, I think you're describing adding
> 
> /sys/class/uio/uioN/dma-mem
> 
> as a means to control /dev/uioN .  Presumably writing to
> /sys/class/uio/uioN/dma-mem would create additional dynamic
> DMA buffers.

No, dma-mem would be a directory containing some more attributes. Maybe one
called "create" that allocates a new buffer.

> 
> I can't yet see a way to make this request-response. When requesting
> a dynamic buffer I need to indicate the size that I want, and in
> return I need to obtain a handle to the buffer (either its mapping
> number, address, etc). Once I have that, I can query other
> interesting information (eg its bus address).

Writing the size to that supposed "create" attribute could allocate the
buffer and and create more attributes that contain the information you need.

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/