From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Minchan Kim <minchan.kim@gmail.com>,
Christoph Lameter <cl@linux.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Rik van Riel <riel@redhat.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 2/2] mm,migration: Fix race between shift_arg_pages and rmap_walk by guaranteeing rmap_walk finds PTEs created within the temporary stack
Date: Sun, 9 May 2010 13:20:52 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.00.1005091309380.3711@i5.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1005091257110.3711@i5.linux-foundation.org>
On Sun, 9 May 2010, Linus Torvalds wrote:
>
> Also - the thing is, we can easily choose to do this _just_ for the case
> of shifting argument pages, which really is a special case (the generic
> case of "mremap()" is a lot more complicated, and doesn't have the issue
> with rmap because it's doing all the "new vma" setup etc).
Looking at the stack setup code, we have other things we probably might
want to look at.
For example, we do that "mprotect_fixup()" to fix up possible vm_flags
issues (notably whether execute bit is set or not), and that's absolutely
something that we probably should do at the same time as moving the stack,
so that we don't end up walking - and changing - the page tables _twice_.
So the stack setup really is a total special case, and it looks like we do
some rather stupid things there. Havign a specialized routine that does
just:
- if we're moving things, fill in the new page tables (we know they are
dense, so my "stupid" routine actually does the right thing despite
being pretty simplistic) before moving.
- if we're moving _or_ changing protections, do a
for_each_page()
move_andor_fix_protection()
which kind of looks like the current "move_page_tables()", except we
know it doesn't need new allocations.
Hmm?
Linus
--
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:[~2010-05-09 20:23 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-06 23:20 [PATCH 0/2] Fix migration races in rmap_walk() V7 Mel Gorman
2010-05-06 23:20 ` [PATCH 1/2] mm,migration: Prevent rmap_walk_[anon|ksm] seeing the wrong VMA information Mel Gorman
2010-05-07 0:56 ` KAMEZAWA Hiroyuki
2010-05-07 16:26 ` Mel Gorman
2010-05-08 15:39 ` Andrea Arcangeli
2010-05-08 17:02 ` Linus Torvalds
2010-05-08 18:04 ` Andrea Arcangeli
2010-05-08 19:51 ` Linus Torvalds
2010-05-09 19:23 ` Mel Gorman
2010-05-06 23:20 ` [PATCH 2/2] mm,migration: Fix race between shift_arg_pages and rmap_walk by guaranteeing rmap_walk finds PTEs created within the temporary stack Mel Gorman
2010-05-07 1:40 ` Linus Torvalds
2010-05-07 1:57 ` KAMEZAWA Hiroyuki
2010-05-07 2:12 ` Linus Torvalds
2010-05-07 4:19 ` KAMEZAWA Hiroyuki
2010-05-07 14:18 ` Linus Torvalds
2010-05-09 19:21 ` Mel Gorman
2010-05-09 19:56 ` Linus Torvalds
2010-05-09 20:06 ` Linus Torvalds
2010-05-09 20:20 ` Linus Torvalds [this message]
2010-05-10 0:40 ` KAMEZAWA Hiroyuki
2010-05-10 1:30 ` Linus Torvalds
2010-05-10 1:32 ` Linus Torvalds
2010-05-10 1:40 ` KAMEZAWA Hiroyuki
2010-05-10 1:49 ` Linus Torvalds
2010-05-10 13:24 ` Mel Gorman
2010-05-10 23:55 ` KAMEZAWA Hiroyuki
2010-05-10 0:42 ` KAMEZAWA Hiroyuki
2010-05-10 14:02 ` Mel Gorman
2010-05-10 13:49 ` Mel Gorman
2010-05-10 0:32 ` KAMEZAWA Hiroyuki
2010-05-07 9:16 ` Mel Gorman
2010-05-07 8:13 ` [PATCH 0/2] Fix migration races in rmap_walk() V7 KAMEZAWA Hiroyuki
-- strict thread matches above, loose matches on Subject: below --
2010-05-06 15:33 [PATCH 0/2] Fix migration races in rmap_walk() V6 Mel Gorman
2010-05-06 15:33 ` [PATCH 2/2] mm,migration: Fix race between shift_arg_pages and rmap_walk by guaranteeing rmap_walk finds PTEs created within the temporary stack Mel Gorman
2010-05-05 13:14 [PATCH 0/2] Fix migration races in rmap_walk() V5 Mel Gorman
2010-05-05 13:14 ` [PATCH 2/2] mm,migration: Fix race between shift_arg_pages and rmap_walk by guaranteeing rmap_walk finds PTEs created within the temporary stack Mel Gorman
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=alpine.LFD.2.00.1005091309380.3711@i5.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
/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