lkml.org 
[lkml]   [1999]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [CFT][PATCH] block_write_*_buffer rewrite

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.

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.255 / U:0.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site