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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.