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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |