linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Greg KH <greg@kroah.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH] fix swapin race condition
Date: Wed, 15 Sep 2010 17:10:36 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.1009151703060.7332@tigran.mtv.corp.google.com> (raw)
In-Reply-To: <20100915234237.GR5981@random.random>

On Thu, 16 Sep 2010, Andrea Arcangeli wrote:
> On Wed, Sep 15, 2010 at 04:02:24PM -0700, Hugh Dickins wrote:
> > I had an afterthought, something I've not thought through fully, but am
> > reminded of by Greg's mail for stable: is your patch incomplete?  Just
> > as it's very unlikely but conceivable the pte_same() test is inadequate,
> > isn't the PageSwapCache() test you've added to do_swap_page() inadequate?
> > Doesn't it need a "page_private(page) == entry.val" test too?
> > 
> > Just as it's conceivable that the same swap has got reused (either via
> > try_to_free_swap or via swapoff+swapon) for a COWed version of the page
> > in that pte slot meanwhile, isn't it conceivable that the page we hold
> 
> Yes, before the fix, the page could be removed from swapcache despite
> being pinned, and the cow copy could reuse the same swap entry and be
> unmapped again so breaking the pte_same check.
> 
> > while waiting for pagelock, has got freed from swap then reallocated to
> > elsewhere on swap meanwhile?  Which, together with your scenario (and I
> > suspect the two unlikelihoods are not actually to be multiplied), would
> > still lead to the wrong result, unless we add the further test.
> 
> For this to happen the page would need to be removed from swapcache
> and then added back to swapcache to a different swap entry. But if
> that happens the "page_table" pointer would be set to a different swap
> entry too, so failing the pte_same check. If the swap entry of the
> page changes the page_table will change with it, so the pte_same check
> will fail in the first place, so at first glance it looks like
> checking the page_private isn't necessary and the pte_same check on
> the page_table is enough.

I agree that if my scenario happened on its own, the pte_same check
would catch it.  But if my scenario happens along with your scenario
(and I'm thinking that the combination is not that much less likely
than either alone), then the PageSwapCache test will succeed and the
pte_same test will succeed, but we're still putting the wrong page into
the pte, since this page is now represented by a different swap entry
(and the page that should be there by our original swap entry).

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>

  reply	other threads:[~2010-09-16  0:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-03 15:39 Andrea Arcangeli
2010-09-03 20:02 ` Andrew Morton
2010-09-04 12:29   ` Andrea Arcangeli
2010-09-03 23:57 ` Rik van Riel
2010-09-06  2:35 ` Hugh Dickins
2010-09-15 23:02   ` Hugh Dickins
2010-09-15 23:42     ` Andrea Arcangeli
2010-09-16  0:10       ` Hugh Dickins [this message]
2010-09-16 21:03         ` Andrea Arcangeli
2010-09-16 21:08           ` Andrea Arcangeli
2010-09-17  2:31           ` Hugh Dickins
2010-09-18 13:19             ` Andrea Arcangeli
2010-09-20  2:35               ` Hugh Dickins
2010-09-20  2:40                 ` [PATCH] mm: further " Hugh Dickins
2010-09-20  3:09                   ` Rik van Riel
  -- strict thread matches above, loose matches on Subject: below --
2010-07-09  0:23 [PATCH] " Andrea Arcangeli
2010-07-09 20:32 ` Hugh Dickins
2010-07-09 21:19   ` Hugh Dickins
2010-07-09 22:02   ` Rik van Riel
2010-07-13  1:08   ` Andrea Arcangeli
2010-07-13 21:30     ` Hugh Dickins

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.DEB.2.00.1009151703060.7332@tigran.mtv.corp.google.com \
    --to=hughd@google.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.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