>
> On Wed, 1 Dec 1999, Alexander Viro wrote:
>
> > 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.
Aiee... Yes, you are right. And it doesn't make me too happy -
I'ld rather have the thing usable for writing from kernel space. And
set_fs() trick is not too nice.
Hmm... What about aliasing the page from kernel space instead of
get_page()?
> > 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.)
And in your scenario with write() from mmaped area it will give
you what? Random junk being written into file, AFAICS.
-
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/