[PATCH] 7/4 -ac to newer rmap

[PATCH] 7/4 -ac to newer rmap

[Rik van Riel]

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 ?

(ObWork: my patches are sponsored by Conectiva, Inc)

--- linux-2.4.19/mm/swap_state.c	2002-11-13 08:48:32.000000000 -0200
+++ linux-2.4-rmap/mm/swap_state.c	2002-11-13 12:10:46.000000000 -0200
@@ -151,8 +151,7 @@
 	if (!PageLocked(page))
 		BUG();
 
-	if (unlikely(!block_flushpage(page, 0)))
-		PAGE_BUG(page);	/* an anonymous page cannot have page->buffers set */
+	block_flushpage(page, 0);
 
 	entry.val = page->index;
 
--
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/

Re: [PATCH] 7/4 -ac to newer rmap

[Andrew Morton]

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/