Re: [patch 2.6.13-rc4] fix get_user_pages bug

Nick Piggin
2005-08-01T10:58:21Z

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