Messages in this thread | | | Date | Sat, 16 Sep 2006 17:42:44 +1000 | From | Nick Piggin <> | Subject | Re: [RFC] PAGE_RW Should be added to PAGE_COPY ? |
| |
(adding linux-mm)
Hugh Dickins wrote:
>>but for the app to use a shared mapping instead of a private. > > > But that suggestion wasn't helpful: you'd much prefer not to > restrict what areas of userspace are used in this way. > > The problem, as I now see it, is precisely with do_wp_page()'s > TestSetPageLocked, as you first said. There is indeed a small > but real chance that will fail. At some time in the past I did > realize that, but pushed it to the back of my mind, waiting for > someone actually to complain: now you have. > > Yes, it would be good if we could do that check in some other, > reliable way. The problem is that can_share_swap_page has to > check page_mapcount (and PageSwapCache) and page_swapcount in > an atomic way: the page lock is what we have used to guard the > movement between mapcount and swapcount. > > I'll try to think whether we can do that better, > but not until next week.
I don't think TestSetPageLocked is the problem. Indeed you may be able to get around a few specific cases say, by turning that into a plain lock_page()... but the problem is still fundamentally COW.
In other words, one should always be able to return 0 from that can_share_swap_page and have the system continue to work... right? Because even if you hadn't done that mprotect trick, you may still have a problem because the page may *have* to be copied on write if it is shared over fork.
So if we filled in the missing mm/ implementation of VM_DONTCOPY (and call it MAP_DONTCOPY rather than the confusing MAP_DONTFORK) such that it withstands such an mprotect sequence, we can then ask that all userspace drivers do their get_user_pages memory on these types of vmas.
Would that work?
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |