Linux MM tree latest commits
 help / color / mirror / Atom feed
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