From: akpm@linux-foundation.org
To: mm-commits@vger.kernel.org
Cc: hughd@google.com, riel@redhat.com, stable@kernel.org
Subject: + mm-further-fix-swapin-race-condition.patch added to -mm tree
Date: Mon, 20 Sep 2010 11:48:26 -0700 [thread overview]
Message-ID: <201009201848.o8KImQsx006539@imap1.linux-foundation.org> (raw)
The patch titled
mm: further fix swapin race condition
has been added to the -mm tree. Its filename is
mm-further-fix-swapin-race-condition.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: mm: further fix swapin race condition
From: Hugh Dickins <hughd@google.com>
Commit 4969c1192d15afa3389e7ae3302096ff684ba655 "mm: fix swapin race
condition" is now agreed to be incomplete. There's a race, not very much
less likely than the original race envisaged, in which it is further
necessary to check that the swapcache page's swap has not changed.
Here's the reasoning: cast in terms of reuse_swap_page(), but probably
could be reformulated to rely on try_to_free_swap() instead, or on
swapoff+swapon.
A, faults into do_swap_page(): does page1 = lookup_swap_cache(swap1) and
comes through the lock_page(page1).
B, a racing thread of the same process, faults on the same address: does
page1 = lookup_swap_cache(swap1) and now waits in lock_page(page1), but
for whatever reason is unlucky not to get the lock any time soon.
A carries on through do_swap_page(), a write fault, but cannot reuse the
swap page1 (another reference to swap1). Unlocks the page1 (but B doesn't
get it yet), does COW in do_wp_page(), page2 now in that pte.
C, perhaps the parent of A+B, comes in and write faults the same swap
page1 into its mm, reuse_swap_page() succeeds this time, swap1 is freed.
kswapd comes in after some time (B still unlucky) and swaps out some pages
from A+B and C: it allocates the original swap1 to page2 in A+B, and some
other swap2 to the original page1 now in C. But does not immediately free
page1 (actually it couldn't: B holds a reference), leaving it in swap
cache for now.
B at last gets the lock on page1, hooray! Is PageSwapCache(page1)? Yes.
Is pte_same(*page_table, orig_pte)? Yes, because page2 has now been given
the swap1 which page1 used to have. So B proceeds to insert page1 into
A+B's page_table, though its content now belongs to C, quite different
from what A wrote there.
B ought to have checked that page1's swap was still swap1.
Signed-off-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff -puN mm/memory.c~mm-further-fix-swapin-race-condition mm/memory.c
--- a/mm/memory.c~mm-further-fix-swapin-race-condition
+++ a/mm/memory.c
@@ -2680,10 +2680,12 @@ static int do_swap_page(struct mm_struct
delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
/*
- * Make sure try_to_free_swap didn't release the swapcache
- * from under us. The page pin isn't enough to prevent that.
+ * Make sure try_to_free_swap or reuse_swap_page or swapoff did not
+ * release the swapcache from under us. The page pin, and pte_same
+ * test below, are not enough to exclude that. Even if it is still
+ * swapcache, we need to check that the page's swap has not changed.
*/
- if (unlikely(!PageSwapCache(page)))
+ if (unlikely(!PageSwapCache(page) || page_private(page) != entry.val))
goto out_page;
if (ksm_might_need_to_copy(page, vma, address)) {
_
Patches currently in -mm which might be from hughd@google.com are
linux-next.patch
proc-pid-smaps-fix-dirty-pages-accounting.patch
proc-pid-smaps-export-amount-of-anonymous-memory-in-a-mapping.patch
rmap-fix-walk-during-fork.patch
unlink_anon_vmas-in-__split_vma-in-case-of-error.patch
mm-further-fix-swapin-race-condition.patch
mm-compaction-fix-compactpagefailed-counting.patch
vmscantmpfs-treat-used-once-pages-on-tmpfs-as-used-once.patch
ipc-shmc-add-rss-and-swap-size-information-to-proc-sysvipc-shm.patch
ipc-shmc-add-rss-and-swap-size-information-to-proc-sysvipc-shm-v2.patch
prio_tree-debugging-patch.patch
reply other threads:[~2010-09-20 18:49 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=201009201848.o8KImQsx006539@imap1.linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=riel@redhat.com \
--cc=stable@kernel.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