Messages in this thread | | | Date | Mon, 30 Nov 2009 12:54:25 +0100 | From | Nick Piggin <> | Subject | Re: get_user_pages question |
| |
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.
| |