From: Andrew Morton <akpm@digeo.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Arjan van de Ven <arjanv@redhat.com>,
linux-mm@kvack.org
Subject: Re: [PATCH] 7/4 -ac to newer rmap
Date: Wed, 13 Nov 2002 11:46:14 -0800 [thread overview]
Message-ID: <3DD2AC06.DD4CC8D1@digeo.com> (raw)
In-Reply-To: <20021113145002Z80262-18062+21@imladris.surriel.com>
Rik van Riel wrote:
>
> I guess that after a truncate() and maybe some special ext3 transactions
> anonymous pages can have page->buffers set. Not quite sure about delete
> from swap cache, though ... maybe the reverse of this patch should be
> applied into the -rmap tree and mainline instead ?
There is special code in mainline 2.4's try_to_swap_out() to
handle these damn pages:
/*
* Anonymous buffercache pages can be left behind by
* concurrent truncate and pagefault.
*/
if (page->buffers)
goto preserve;
These pages are very rare. And we rather have to do this because
the buffers may be of the wrong blocksize.
And look, you've already fixed it, in page_launder_zone():
if (page->pte_chain && !page->mapping && !page->buffers) {
So block_flushpage() "has to succeed" in there. The only path to those
buffers is via the page, and the page is locked and there is no IO
under way and swapcache is not coherent with the blockdev mapping.
(If one of those buffers _is_ locked, block_flushpage() does lock_buffer()
inside spinlock).
It's not the most glorious part of the kernel.
--
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/
prev parent reply other threads:[~2002-11-13 19:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-13 14:50 Rik van Riel
2002-11-13 19:46 ` Andrew Morton [this message]
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=3DD2AC06.DD4CC8D1@digeo.com \
--to=akpm@digeo.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjanv@redhat.com \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
/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