> 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.
When a kernel mapping is created for a given user-page. Doesn't the reference
count for the page be "2", one for the user and one for the kernel. Doesn't
the page structure maintain a reference count ?
Also when a kernel mapping is created, shouldn't the page accquire a property
of staying around, even if the user mapping goes off ? Because when the user
process goes off the page * should * not go back to the free pool, but stay
around as the "ref cnt" is now "1". Also it should always stay in memory, because
the page is still locked. If a process was the only user for the page when
the memory cleanup occurs as part of exit(), the page will go back to the free pool
and lose its property of being locked.
But i do accept one likely problem in such DMA's. In case the driver is waiting
for the DMA to happen/complete and an un-advertised exit() happens:
This will more likely cause kernel memory VM and the pages behind them to be eaten
up, as there is no one to free them if the process goes off un-advertised. This
is assuming that the process had called exit() in the interruptible blocking call
itself on receipt of say a SIGSEGV ( for a multi-threaded case ), or some other
fatal exit criteria.
I have another question:
Doesn't the above happen for the case for allocation of kernel buffers and mmap
to the user ? I mean who will free the kernel buffers in this case ?
thanks,
Rama.
-
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/