From: Hugh Dickins <hugh@veritas.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
Andrew Morton <akpm@osdl.org>, Robin Holt <holt@sgi.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, Ingo Molnar <mingo@elte.hu>,
Nick Piggin <nickpiggin@yahoo.com.au>,
Roland McGrath <roland@redhat.com>
Subject: Re: [patch 2.6.13-rc4] fix get_user_pages bug
Date: Tue, 2 Aug 2005 18:21:09 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.61.0508021809530.5659@goblin.wat.veritas.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0508020911480.3341@g5.osdl.org>
On Tue, 2 Aug 2005, Linus Torvalds wrote:
> On Tue, 2 Aug 2005, Hugh Dickins wrote:
> >
> > But have I just realized a non-s390 problem with your pte_dirty
> > technique? The ptep_set_wrprotect in fork's copy_one_pte.
> >
> > That's specifically write-protecting the pte to force COW, but leaving
> > the dirty bit: so now get_user_pages will skip COW-ing it (in all write
> > cases, not just the peculiar ptrace force one).
>
> Damn, you're right. We could obviously move the dirty bit from the page
> tables to the "struct page" in fork() (that may have other advantages:
> we're scanning the dang thing anyway, after all) to avoid that special
> case, but yes, that's nasty.
It might not be so bad. It's going to access the struct page anyway.
And clearing dirty from parent and child at fork time could save two
set_page_dirtys at exit time. But I'm not sure that we could batch the
the dirty bit clearing into one TLB flush like we do the write protection.
> In fact, that brings up another race altogether: a thread that does a
> fork() at the same time as get_user_pages() will have the exact same
> issues. Even with the old code. Simply because we test the permissions on
> the page long before we actually do the real access (ie it may be dirty
> and writable when we get it, but by the time the write happens, it might
> have become COW-shared).
>
> Now, that's probably not worth worrying about, but it's kind of
> interesting.
Not worth worrying about in this context: it's one aspect of the
InfiniBand (RDMA) issue I was referring to, to be addressed another time.
Or is it even possible? We do require the caller of get_user_pages to
down_read(&mm->mmap_sem), and fork parent has down_write(&mm->mmap_sem).
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-08-02 17:21 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-30 20:53 get_user_pages() with write=1 and force=1 gets read-only pages Robin Holt
2005-07-30 22:13 ` Hugh Dickins
2005-07-31 1:52 ` Nick Piggin
2005-07-31 10:52 ` Robin Holt
2005-07-31 11:07 ` Nick Piggin
2005-07-31 11:30 ` Robin Holt
2005-07-31 11:39 ` Robin Holt
2005-07-31 12:09 ` Robin Holt
2005-07-31 22:27 ` Nick Piggin
2005-08-01 3:22 ` Roland McGrath
2005-08-01 8:21 ` [patch 2.6.13-rc4] fix get_user_pages bug Nick Piggin
2005-08-01 9:19 ` Ingo Molnar
2005-08-01 9:27 ` Nick Piggin
2005-08-01 10:15 ` Ingo Molnar
2005-08-01 10:57 ` Nick Piggin
2005-08-01 19:43 ` Hugh Dickins
2005-08-01 20:08 ` Linus Torvalds
2005-08-01 21:06 ` Hugh Dickins
2005-08-01 21:51 ` Linus Torvalds
2005-08-01 22:01 ` Linus Torvalds
2005-08-02 12:01 ` Martin Schwidefsky
2005-08-02 12:26 ` Hugh Dickins
2005-08-02 12:28 ` Nick Piggin
2005-08-02 15:19 ` Martin Schwidefsky
2005-08-02 15:30 ` Linus Torvalds
2005-08-02 16:03 ` Hugh Dickins
2005-08-02 16:25 ` Linus Torvalds
2005-08-02 17:02 ` Linus Torvalds
2005-08-02 17:27 ` Hugh Dickins
2005-08-02 17:21 ` Hugh Dickins [this message]
2005-08-02 18:47 ` Linus Torvalds
2005-08-02 19:20 ` Hugh Dickins
2005-08-02 19:54 ` Linus Torvalds
2005-08-02 20:55 ` Hugh Dickins
2005-08-03 10:24 ` Nick Piggin
2005-08-03 11:47 ` Hugh Dickins
2005-08-03 12:13 ` Nick Piggin
2005-08-03 16:12 ` Linus Torvalds
2005-08-03 16:39 ` Linus Torvalds
2005-08-03 16:42 ` Linus Torvalds
2005-08-03 17:12 ` Hugh Dickins
2005-08-03 23:03 ` Nick Piggin
2005-08-04 14:14 ` Alexander Nyberg
2005-08-04 14:30 ` Nick Piggin
2005-08-04 15:00 ` Alexander Nyberg
2005-08-04 15:35 ` Hugh Dickins
2005-08-04 16:32 ` Russell King
2005-08-04 15:36 ` Linus Torvalds
2005-08-04 16:29 ` Russell King
2005-08-03 10:24 ` Martin Schwidefsky
2005-08-03 11:57 ` Hugh Dickins
2005-08-02 16:44 ` Martin Schwidefsky
2005-08-01 15:42 ` Linus Torvalds
2005-08-01 18:18 ` Linus Torvalds
2005-08-03 8:24 ` Robin Holt
2005-08-03 11:31 ` Hugh Dickins
2005-08-04 11:48 ` Robin Holt
2005-08-04 13:04 ` Hugh Dickins
2005-08-01 19:29 ` Hugh Dickins
2005-08-01 19:48 ` Linus Torvalds
2005-08-02 8:07 ` Martin Schwidefsky
2005-08-01 19:57 ` Andrew Morton
2005-08-01 20:16 ` Linus Torvalds
2005-08-02 0:14 ` Nick Piggin
2005-08-02 1:27 ` Nick Piggin
2005-08-02 3:45 ` Linus Torvalds
2005-08-02 4:25 ` Nick Piggin
2005-08-02 4:35 ` Linus Torvalds
2005-08-01 20:03 ` Hugh Dickins
2005-08-01 20:12 ` Andrew Morton
2005-08-01 20:26 ` Linus Torvalds
2005-08-01 20:51 ` Hugh Dickins
2005-08-02 14:02 Dan Higgins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.61.0508021809530.5659@goblin.wat.veritas.com \
--to=hugh@veritas.com \
--cc=akpm@osdl.org \
--cc=holt@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=roland@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox