Messages in this thread | | | Date | Mon, 01 Aug 2005 20:57:37 +1000 | From | Nick Piggin <> | Subject | Re: [patch 2.6.13-rc4] fix get_user_pages bug |
| |
Ingo Molnar wrote:
> > Hugh's posting said: > > "it's trying to avoid an endless loop of finding the pte not writable > when ptrace is modifying a page which the user is currently protected > against writing to (setting a breakpoint in readonly text, perhaps?)" > > i'm wondering, why should that case generate an infinite fault? The > first write access should copy the shared-library page into a private > page and map it into the task's MM, writable. If this make-writable
It will be mapped readonly.
> operation races with a read access then we return a minor fault and the > page is still readonly, but retrying the write should then break up the > COW protection and generate a writable page, and a subsequent > follow_page() success. If the page cannot be made writable, shouldnt the > vma flags reflect this fact by not having the VM_MAYWRITE flag, and > hence get_user_pages() should have returned with -EFAULT earlier? >
If it cannot be written to, then yes. If it can be written to but is mapped readonly then you have the problem.
Aside, that brings up an interesting question - why should readonly mappings of writeable files (with VM_MAYWRITE set) disallow ptrace write access while readonly mappings of readonly files not? Or am I horribly confused?
-- 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/
| |