Re: [patch 2.6.13-rc4] fix get_user_pages bug

From: Hugh Dickins (hugh_at_veritas.com)
Date: 08/01/05

  • Next message: hermann pitton: "Re: 2 errors in 2.6.12" 
    Date:	Mon, 1 Aug 2005 20:43:30 +0100 (BST)
To: Nick Piggin <nickpiggin@yahoo.com.au>

    On Mon, 1 Aug 2005, Nick Piggin wrote:
    > 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.

    Yes. Sorry to leave you so long pondering over my words!

    > > 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.

    Yes. The problem case is the one where "maybe_mkwrite" finds !VM_WRITE
    and so doesn't set writable (but as Linus has observed, dirty is set).

    I'm no expert on that case, was just guessing its use, I think Robin
    determined that Roland is the expert on it; but what's very clear is
    that it's intentional, allowing strace to write where the user cannot
    currently write.

    > 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?

    Either you or I. You'll have to spell that out to me in more detail,
    I don't see it that way.

    What I do see and am slightly disturbed by, is that do_wp_page on a
    shared maywrite but not currently writable area, will go the break
    cow route in mainline, and has done so forever; whereas my page_mkwrite
    fixes in -mm inadvertently change that to go the the reuse route.

    I think my inadvertent change is correct, and the current behaviour
    (putting anonymous pages into a shared vma) is surprising, and may
    have bad consequences (would at least get the overcommit accounting
    wrong).

    Hugh
    -
    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/

  • Next message: hermann pitton: "Re: 2 errors in 2.6.12"