Messages in this thread | | | Date | Tue, 14 Apr 2009 21:02:47 +0900 | Subject | Re: [RFC][PATCH v3 1/6] mm: Don't unmap gup()ed page | From | KOSAKI Motohiro <> |
| |
> On Tuesday 14 April 2009 16:16:52 KOSAKI Motohiro wrote: > >> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> >> Sugessted-by: Linus Torvalds <torvalds@osdl.org> > > "Suggested-by:" ;)
Agghh, thanks.
>> @@ -547,7 +549,13 @@ int reuse_swap_page(struct page *page) >> SetPageDirty(page); >> } >> } >> - return count == 1; >> + >> + /* >> + * If we can re-use the swap page _and_ the end >> + * result has only one user (the mapping), then >> + * we reuse the whole page >> + */ >> + return count + page_count(page) == 2; >> } > > I guess this patch does work to close the read-side race, but I slightly don't > like using page_count for things like this. page_count can be temporarily > raised for reasons other than access through their user mapping. Swapcache, > page reclaim, LRU pagevecs, concurrent do_wp_page, etc.
Yes, that's trade-off. your early decow also can misjudge and make unnecessary copy.
>> /* >> + * Don't pull an anonymous page out from under get_user_pages. >> + * GUP carefully breaks COW and raises page count (while holding >> + * pte_lock, as we have here) to make sure that the page >> + * cannot be freed. If we unmap that page here, a user write >> + * access to the virtual address will bring back the page, but >> + * its raised count will (ironically) be taken to mean it's not >> + * an exclusive swap page, do_wp_page will replace it by a copy >> + * page, and the user never get to see the data GUP was holding >> + * the original page for. >> + * >> + * This test is also useful for when swapoff (unuse_process) has >> + * to drop page lock: its reference to the page stops existing >> + * ptes from being unmapped, so swapoff can make progress. >> + */ >> + if (PageSwapCache(page) && >> + page_count(page) != page_mapcount(page) + 2) { >> + ret = SWAP_FAIL; >> + goto out_unmap; >> + } > > I guess it does add another constraint to the VM, ie. not allowed to > unmap an anonymous page with elevated refcount. Maybe not a big deal > now, but I think it is enough that it should be noted. If you squint, > this could actually be more complex/intrusive to the wider VM than my > copy on fork (which is basically exactly like a manual do_wp_page at > fork time).
I agree this code effect widely kernel activity. but actually, in past days, the kernel did the same behavior. then almost core code is page_count checking safe.
but Yes, we need to afraid newer code don't works with this code...
> And.... I don't think this is safe against a concurrent gup_fast() > (which helps my point).
Could you please explain more detail ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |