Messages in this thread | | | Date | Thu, 2 Dec 1999 11:36:32 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [CFT][PATCH] block_write_*_buffer rewrite |
| |
On Thu, 2 Dec 1999, Ingo Molnar wrote:
> > 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/
| |