* Nick Piggin <[email protected]> wrote:
> Ingo Molnar wrote:
> >* Nick Piggin <[email protected]> wrote:
>
> >>Feedback please, anyone.
> >
> >
> >it looks good to me, but wouldnt it be simpler (in terms of patch and
> >architecture impact) to always retry the follow_page() in
> >get_user_pages(), in case of a minor fault? The sequence of minor faults
>
> I believe this can break some things. Hugh posted an example in his
> recent post to linux-mm (ptrace setting a breakpoint in read-only
> text). I think?
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
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?
in other words, can a named MAP_PRIVATE vma with VM_MAYWRITE set ever be
non-COW-break-able and thus have the potential to induce an infinite
loop?
Ingo
-
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]
| |
 |