Re: get_user_pages question

[Nick Piggin <npiggin@suse.de>]

On Sat, Nov 28, 2009 at 07:50:52PM +0100, Andrea Arcangeli wrote:
> All other patches floating around spread an mm-wide semaphore over
> fork fast path, and across O_DIRECT, nfs, and aio, and they most
> certainly didn't fix the two races for all gup users, and they weren't
> stable because of having to identify the closure of the I/O across all
> possible put_page. That approach kind of opens a can of worms and it
> looks the wrong way to go to me, and I think they scale worse too for
> the fast path (no O_DIRECT or no fork). Identifying the gup closure
> points and replacing the raw put_page with gup_put_page would not be
> an useless effort though and I felt if the gup API was just a little
> bit more sophisticated I could simplify a bit the put_compound_page to
> serialize the race against split_huge_page_refcount, but this is an
> orthogonal issue with the mm-wide semaphore release addition which I
> personally dislike.

IIRC, the last time this came up, it kind of became stalled on this
point. Linus hated our "preemptive cow" approaches, and thought the
above approach was better.

I don't think we need to bother arguing details between our former
approaches until we get past this sticking point.

FWIW, I need to change get_user_pages semantics somewhat because we
have filesystems that cannot tolerate a set_page_dirty() to dirty a
clean page (it must only be dirtied with page_mkwrite).

This should probably require converting callers to use put_user_pages
and disallowing lock_page, mmap_sem, user-copy etc. within these
sections.