lkml.org 
[lkml]   [2005]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-08-01 13:01    [W:0.147 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site