From: Andrea Arcangeli <aarcange@redhat.com>
To: Hugh Dickins <hughd@google.com>
Cc: Nai Xia <nai.xia@gmail.com>, Mel Gorman <mgorman@suse.de>,
Pawel Sikora <pluto@agmk.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, jpiszcz@lucidpixels.com, arekm@pld-linux.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mremap: enforce rmap src/dst vma ordering in case of vma_merge succeeding in copy_vma
Date: Sat, 5 Nov 2011 04:07:18 +0100 [thread overview]
Message-ID: <20111105030718.GV18879@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1111041856530.22199@sister.anvils>
On Fri, Nov 04, 2011 at 07:21:28PM -0700, Hugh Dickins wrote:
> I found Andrea's "anon_vma_merge" reply very hard to understand; but
> it looks like he now accepts that it was mistaken, or on the wrong
> track at least...
No matter how we get the order right, we still need to reverse the
order in case of error without taking the lock. So even allocating a
new vma every time wouldn't be enough to get out of the ordering
games (it would be enough in the non-error path of course...).
So there are a couple of ways:
1) Keep my patch (adjust comment) and add a second ordering call in
the error path. Cleanup the *vmap case.
2) Always allocate a new vma, merge later, and still keep my patch for
reversing the order in the error path only (not an huge improvement
if we still have to reverse the order). So this now looks the worst
option at the light of the error path which would give
trouble by going the opposite way... again.
3) Return to your fix that takes the anon_vma lock during the pte
moves
Fixing my patch requires just a one liner to fix the error path, it's
not like the patch was wrong in fact it reduced the window even more,
it just missed one liner in the error path.
But it's still doing reordering. Which I think is safe and not
fundamentally different in ordering terms by the old anon_vma logic
before _chain (which is why this bug could have triggered before
too). But certainly more complex than taking the anon_vma lock around
every pagetable move, that's for sure. fork will still relay on the
ordering but fork has a super easy life compared to mremap which goes
both ways and has vma_merge in it too which makes the vma order non
deterministic.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-11-05 3:07 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201110122012.33767.pluto@agmk.net>
[not found] ` <alpine.LSU.2.00.1110131547550.1346@sister.anvils>
2011-10-13 23:30 ` kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110 Hugh Dickins
2011-10-16 16:11 ` Christoph Hellwig
2011-10-16 23:54 ` Andrea Arcangeli
2011-10-17 18:51 ` Hugh Dickins
2011-10-17 22:05 ` Andrea Arcangeli
2011-10-19 7:43 ` Mel Gorman
2011-10-19 13:39 ` Linus Torvalds
2011-10-19 19:42 ` Hugh Dickins
2011-10-20 6:30 ` Paweł Sikora
2011-10-20 6:51 ` Linus Torvalds
2011-10-21 6:54 ` Nai Xia
2011-10-21 7:35 ` Pawel Sikora
2011-10-20 12:51 ` Nai Xia
2011-10-20 18:36 ` Hugh Dickins
2011-10-21 6:22 ` Nai Xia
2011-10-21 8:07 ` Pawel Sikora
2011-10-21 9:07 ` Nai Xia
2011-10-21 21:36 ` Paweł Sikora
2011-10-22 6:21 ` Nai Xia
2011-10-22 16:42 ` Paweł Sikora
2011-10-20 9:11 ` Nai Xia
2011-10-21 15:56 ` Mel Gorman
2011-10-21 17:21 ` Nai Xia
2011-10-21 17:41 ` Andrea Arcangeli
2011-10-21 22:50 ` Andrea Arcangeli
2011-10-22 5:52 ` Nai Xia
2011-10-31 17:14 ` Andrea Arcangeli
2011-10-31 17:27 ` [PATCH] mremap: enforce rmap src/dst vma ordering in case of vma_merge succeeding in copy_vma Andrea Arcangeli
2011-11-01 12:07 ` Mel Gorman
2011-11-01 14:35 ` Nai Xia
2011-11-04 7:31 ` Hugh Dickins
2011-11-04 14:34 ` Nai Xia
2011-11-04 15:59 ` Pawel Sikora
2011-11-05 2:21 ` Nai Xia
2011-11-04 19:16 ` Hugh Dickins
2011-11-04 20:54 ` Andrea Arcangeli
2011-11-05 0:09 ` Nai Xia
2011-11-05 2:21 ` Hugh Dickins
2011-11-05 3:07 ` Andrea Arcangeli [this message]
2011-11-05 17:06 ` Andrea Arcangeli
2011-12-08 3:24 ` David Rientjes
2011-12-08 12:42 ` Andrea Arcangeli
2011-12-09 0:08 ` Andrew Morton
2011-12-09 1:55 ` Andrea Arcangeli
2011-11-04 23:56 ` Andrea Arcangeli
2011-11-05 0:21 ` Nai Xia
2011-11-05 0:59 ` Nai Xia
2011-11-05 1:33 ` Andrea Arcangeli
2011-11-05 2:00 ` Nai Xia
2011-11-07 13:14 ` Mel Gorman
2011-11-07 15:42 ` Andrea Arcangeli
2011-11-07 16:28 ` Mel Gorman
2011-11-09 1:25 ` Andrea Arcangeli
2011-11-11 9:14 ` Nai Xia
2011-11-16 14:00 ` Andrea Arcangeli
2011-11-17 0:16 ` Hugh Dickins
2011-11-17 2:49 ` Nai Xia
2011-11-17 6:21 ` Nai Xia
2011-11-17 18:42 ` Andrea Arcangeli
2011-11-18 1:42 ` Nai Xia
2011-11-18 2:17 ` Andrea Arcangeli
2011-11-19 9:15 ` Nai Xia
2011-10-22 5:07 ` kernel 3.0: BUG: soft lockup: find_get_pages+0x51/0x110 Nai Xia
2011-10-31 16:34 ` Andrea Arcangeli
2011-10-16 22:37 ` Linus Torvalds
2011-10-17 3:02 ` Hugh Dickins
2011-10-17 3:09 ` Linus Torvalds
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=20111105030718.GV18879@redhat.com \
--to=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arekm@pld-linux.org \
--cc=hughd@google.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=nai.xia@gmail.com \
--cc=pluto@agmk.net \
/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;
as well as URLs for NNTP newsgroup(s).