Why?
See below.
Reasons why shared writable pages might be a problem:
1) You aren't taking an atomic snapshot of the contents of that
memory.
I don't care about this, I totally agree with you about ext2 bitmaps
etc. and that in these cases the user is responsible about insuring
mutual exclusion in such a shared memory area which is being written
to disk via raw I/O.
There _is_ one place where I do think that the current implementation
is lacking: I expect that we probably need a flush-page-to-memory for
writable pages before doing any WRITE, and a cache flush after doing a
READ operation. Dave, comments on this?
Bingo...
As stated above, the user is responsible about ensuring safe access to
the shared memory region.
However any page which the user could have potentially written to must
be flush_cache_page()'d before we can safely raw I/O it to the disk.
Indeed. That and the moving of the page stuff into linux/mm/ are
already on the TODO list, but I want to make sure that the core
functionality and semantics are sound before splitting the code up or
fine-tuning the performance.
Right.
I'm not sure: all we need is a quick page table traversal to find out
whether you have read access with user privilege and that, if
appropriate, the pages are writable. If that is satisfied, then I'm not
sure that we need to consult the vma at all.
It was just a heuristic to detect "funny" usage. Honestly I've never
seen a useful application of doing high bandwidth I/O from userspace
across VMA boundaries. Have you?
Later,
David S. Miller
davem@dm.cobaltmicro.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/