------_=_NextPart_001_01BE923F.A4E98480
Content-Type: text/plain;
charset="iso-8859-1"
> I have just started looking at Linux code. So i am not sure
> how this fits into
> the Linux context in terms of the Linux code/calls. But the
> following idea might help.
>
> If your sure of the address being read from the ISR.
>
> a) Lock that user address into memory.
> b) Map this user page(s) into the kernel address space.
>
> As part of ISR, you can read the data now from this kernel
> address. In this case you
> don't have to worry about if the process is currently
> running or not.
I have written some code that does this properly. It properly locks pages,
handles copy-on-write pages, and detects (and throws out, as it should)
attempts to lock mmap'd or page cache memory. However, there is still a
FATAL flaw in the code-- since the driver thread that locked the buffers
runs in process context, if the process is killed while the driver is
blocked awaiting DMA completion -- and the device is writing into user space
-- the device can potentially be STILL DMA'ing into that memory after it has
been free'd by the kernel, put into the page cache, allocated to a new
process, etc.
Without a mechanism to allow the driver to be notified the process has died
to stop the DMA disk buffers could be destroyed, processes overwritten, etc.
This is a BAD THING.
The ultimate solution to this will more than likely be a method to map
vmalloc()'d kernel memory into user space via mmap(). (See the bttv driver)
While this is ugly in and of itself, it's better than the alternatives.
There are simply too many issues to consider here to make it a viable
solution, unless a way becomes apparent to handle page cache memory DMA,
peer-to-peer DMA, and callbacks without much extra effort (yeah right).
-- Eric Lowe elowe@systran.com Software Engineer Co-op, Systran Corporation 937-252-5601 x330 ((my apologies for the HTML garbage, it's put on by my e-mail gateway))------_=_NextPart_001_01BE923F.A4E98480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: Process VM Addr to Kernel VM Addr at Interrupt Time. > I have just started looking at Linux = code. So i am not sure
> how this fits into
> the Linux context in terms of the = Linux code/calls. But the
> following idea might help.
>
> If your sure of the address being = read from the ISR.
>
> a) Lock that user address = into memory.
> b) Map this user page(s) into = the kernel address space.
>
> As part of ISR, you can read the = data now from this kernel
> address. In this case you
> don't have to worry about if the = process is currently
> running or not.I have written some code that does this = properly. It properly locks pages, handles copy-on-write pages, = and detects (and throws out, as it should) attempts to lock mmap'd or = page cache memory. However, there is still a FATAL flaw in the = code-- since the driver thread that locked the buffers runs in process = context, if the process is killed while the driver is blocked awaiting = DMA completion -- and the device is writing into user space -- the = device can potentially be STILL DMA'ing into that memory after it has = been free'd by the kernel, put into the page cache, allocated to a new = process, etc.
Without a mechanism to allow the driver to be = notified the process has died to stop the DMA disk buffers could be = destroyed, processes overwritten, etc. This is a BAD = THING.
The ultimate solution to this will more than likely = be a method to map vmalloc()'d kernel memory into user space via = mmap(). (See the bttv driver) While this is ugly in and of = itself, it's better than the alternatives. There are simply too = many issues to consider here to make it a viable solution, unless a way = becomes apparent to handle page cache memory DMA, peer-to-peer DMA, and = callbacks without much extra effort (yeah right).
--
------_=_NextPart_001_01BE923F.A4E98480--
Eric Lowe
elowe@systran.com
Software Engineer Co-op, Systran Corporation
937-252-5601 x330
((my apologies for the HTML garbage, it's put on by = my e-mail gateway))- 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/