From: Marcelo Tosatti <marcelo@conectiva.com.br>
To: Linus Torvalds <torvalds@transmeta.com>, Hugh Dickins <hugh@veritas.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
lkml <linux-kernel@vger.kernel.org>
Subject: 2.4.10pre VM changes: Potential race condition on swap code
Date: Tue, 11 Sep 2001 19:40:01 -0300 (BRT) [thread overview]
Message-ID: <Pine.LNX.4.21.0109111919260.1581-100000@freak.distro.conectiva> (raw)
Hi,
It seems there is a potential race caused by swap changes. The reason is
that we do not increase the swap entry on swapin readahead. The comment on
top of swap_duplicate() in read_swap_cache_async() says:
/*
* Make sure the swap entry is still in use. It could have gone
* while caller waited for BKL, or while allocating page above,
* or while allocating page in prior call via swapin_readahead.
*/
if (!swap_duplicate(entry)) /* Account for the swap cache */
goto out_free_page;
The BLK protects the logic against concurrent read_swap_cache_async()
calls, but it does not protect get_swap_page() in try_to_swap_out().
I do not see what protects us (increasing the swap map entry on
valid_swaphandles on older kernels used to be the protection) against the
following race:
- swapin_readahead() finds used entry on swap map. (valid_swaphandles)
- user of this entry deletes the swap map entry, so it becomes free. Then:
CPU0 CPU1
read_swap_cache_async() try_to_swap_out()
Second __find_get_page() fails
get_swap_page() returns swap
entry which CPU0 is trying to read
from.
swap_duplicate() for the entry
succeeds: CPU1 just allocated it.
add_to_swap_cache() add_to_swap_cache()
Now we got two pages on the hash tables for the "same" data. From this
point on there is no guarantee _which_ data will be returned when searched
via pagecache lookup.
Linus, Hugh ?
next reply other threads:[~2001-09-12 0:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-11 22:40 Marcelo Tosatti [this message]
2001-09-11 0:14 ` 2.4.10pre VM changes: Potential race condition on swap code Hugh Dickins
2001-09-13 1:35 ` Marcelo Tosatti
2001-09-13 7:15 ` Hugh Dickins
2001-09-13 19:34 ` Marcelo Tosatti
2001-09-13 20:31 ` Marcelo Tosatti
2001-09-13 20:36 ` Marcelo Tosatti
2001-09-13 22:04 ` Marcelo Tosatti
2001-09-13 22:29 ` Marcelo Tosatti
2001-09-14 13:14 ` Hugh Dickins
2001-09-14 11:45 ` Hugh Dickins
2001-09-14 18:05 ` Marcelo Tosatti
2001-09-14 19:44 ` Marcelo Tosatti
2001-09-14 21:55 ` Hugh Dickins
2001-09-14 21:10 ` Marcelo Tosatti
2001-09-15 0:12 ` Hugh Dickins
2001-09-15 6:29 ` Hugh Dickins
2001-09-15 11:39 ` [PATCH] Re: 2.4.10pre VM changes: Potential race Hugh Dickins
2001-09-17 18:49 ` Marcelo Tosatti
2001-09-18 4:00 ` Marcelo Tosatti
2001-09-22 9:19 ` 2.4.10pre VM changes: Potential race condition on swap code Andrea Arcangeli
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=Pine.LNX.4.21.0109111919260.1581-100000@freak.distro.conectiva \
--to=marcelo@conectiva.com.br \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=torvalds@transmeta.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;
as well as URLs for NNTP newsgroup(s).