> On Wed, 1 Dec 1999, Ingo Molnar wrote:
>
> > the problem is generic_file_write() locking the page while generating a
> > page fault (to the same page).
>
> OK, folks. Proposed fix:
> a) new function: pin_user_page(address); finds a page, faults it
> in, does get_page() and returns the struct page *.
we kindof have this already, it's embedded in map_user_kiobuf() &
follow_page().
> b) generic_file_write() doing it on consequent pages of user data
> _before_ calling write_one_page() and releasing them once they are not
> needed (we can have at most 2 at any moment).
> c) block_write_partial_page() and friends use memcpy() instead of
> copy_from_user(). verify_area() is done by generic_file_write().
__generic_copy_from_user_nocheck() is the thing to be used i think - we
should not assume memcpy() works for (even if present) user-mappings.
> Comments? The new rule being that we should never do
> copy_from_user() while holding lock on any page and should pin the source
> while we don't hold any locks.
i dont know. This interface breaks once we start doing multi-page
pagecache. We might want to simply unlock the page when doing the copy.
This also means that block allocation has to be done a bit more careful,
and partial writes first have to clear the whole page. (because the
unlocked page might be mmap()-ed or read() while the 'unlocked write' is
in progress.)
-- mingo
-
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/