From: Andrea Arcangeli <andrea@suse.de>
To: Hugh Dickins <hugh@veritas.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
linux-kernel@vger.kernel.org
Subject: Re: pre12 VM doubts and patch
Date: Wed, 19 Sep 2001 23:28:18 +0200 [thread overview]
Message-ID: <20010919232818.T720@athlon.random> (raw)
In-Reply-To: <Pine.LNX.4.21.0109191850370.1133-100000@localhost.localdomain> <Pine.LNX.4.21.0109192026280.1502-100000@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.21.0109192026280.1502-100000@localhost.localdomain>; from hugh@veritas.com on Wed, Sep 19, 2001 at 08:42:39PM +0100
On Wed, Sep 19, 2001 at 08:42:39PM +0100, Hugh Dickins wrote:
> --- 2.4.10-pre12/mm/swap_state.c Wed Sep 19 14:05:54 2001
> +++ linux/mm/swap_state.c Mon Sep 17 06:30:26 2001
> @@ -23,6 +23,17 @@
> */
> static int swap_writepage(struct page *page)
> {
> + /* One for the page cache, one for this user, one for page->buffers */
> + if (page_count(page) > 2 + !!page->buffers)
this is racy, you have to spin_lock(&pagecache_lock) before you can
expect the page_count() stays constant. then after you checked the page
has count == 1, you must atomically drop it from the pagecache so it's
not visible anymore to the swapin lookups.
Another way to fix the race is to change lookup_swap_cache to do
find_lock_page instead of find_get_page, and then check the page is
still a swapcachepage after you got it locked (that was the old way,
somebody changed it and introduced the race, I like lookup_swap_cache to
use find_get_page so I dropped such check to fix it, it was a minor
optimization but yes probably worthwhile to reintroduce after addressing
this race in one of the two ways described).
It is also buggy, if something it should be "page_count(page) != 1" (not
!= 2).
> + goto in_use;
> + if (swap_count(page) > 1)
> + goto in_use;
> +
> + delete_from_swap_cache_nolock(page);
> + UnlockPage(page);
> + return 0;
> +
> +in_use:
> rw_swap_page(WRITE, page);
> return 0;
> }
Andrea
next prev parent reply other threads:[~2001-09-19 21:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-19 17:57 pre12 VM doubts and patch Hugh Dickins
2001-09-19 19:42 ` Hugh Dickins
2001-09-19 21:28 ` Andrea Arcangeli [this message]
2001-09-19 23:16 ` Linus Torvalds
2001-09-19 23:31 ` Andrea Arcangeli
2001-09-19 23:49 ` Andrea Arcangeli
2001-09-20 1:04 ` Jeff Chua
2001-09-20 1:05 ` Andrea Arcangeli
2001-09-20 1:12 ` Jeff Chua
2001-09-19 23:51 ` Hugh Dickins
2001-09-20 0:01 ` Andrea Arcangeli
2001-09-20 5:12 ` Andrea Arcangeli
2001-09-20 5:58 ` Linus Torvalds
2001-09-20 6:08 ` Andrea Arcangeli
2001-09-20 6:15 ` Linus Torvalds
2001-09-20 6:34 ` Andrea Arcangeli
2001-09-20 6:26 ` Andrea Arcangeli
2001-09-20 6:31 ` Linus Torvalds
2001-09-20 6:38 ` 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=20010919232818.T720@athlon.random \
--to=andrea@suse.de \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@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