Date: Mon, 8 Mar 2004 16:59:37 -0800
From: Andrew Morton <akpm@osdl.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in
 <=16G machines)
Message-Id: <20040308165937.562e3d29.akpm@osdl.org>
In-Reply-To: <20040309003550.GL12612@dualathlon.random>
References: <20040308202433.GA12612@dualathlon.random>
	<Pine.LNX.4.58.0403081238060.9575@ppc970.osdl.org>
	<20040308132305.3c35e90a.akpm@osdl.org>
	<20040308230247.GC12612@dualathlon.random>
	<20040308152126.54f4f681.akpm@osdl.org>
	<20040308234014.GG12612@dualathlon.random>
	<20040308161046.04270108.akpm@osdl.org>
	<20040309003550.GL12612@dualathlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2128
Lines: 49

Andrea Arcangeli <andrea@suse.de> wrote:
>
> btw, this reminds me another trouble, that is what to do in the case
> where in 2.4 we convert file-mapped-pages into anonymous pages while
> they're still mapped (I don't remeber exactly what could do that but it
> could happen, do you remember the details? I think this is the case that
> Hugh calls the Morton pages, he also had troubles in his anobjrmap
> attempt but I think it was more a fixme comment). In 2.4 the swap_out
> had to deal with that somehow, but with my anobjrmap the vm will now
> lose track of those pages, so they will become unswappable. Not sure if
> they were unswappable in 2.4 too and/or if 2.6-rmap could leave them
> visible to the vm or not.
> 
> Also these pages should be swapped to the swap device, if something,
> they lost reference of the inode.
> 
> Input on the Morton pages is appreciated ;)

You mean Dickens pages ;)

They were caused by a race between truncate and filemap_nopage(), iirc. 
nopage was sleeping on the read I/O and truncate would come in and tear
down the pagetables.  Then the read I/O completes and nopage reinstantiates
the page outside i_size after truncate ripped it off the mapping.  truncate
was unable to free the page because ext3 happened to have a ref via the
page's buffer_heads.  Something like that.

But these pages should no longer exist, due to the truncate_count logic in
do_no_page().


However I'm not sure that this (truly revolting) problem which Rajesh
identified:

http://www.ussg.iu.edu/hypermail/linux/kernel/0402.2/1155.html

Cannot cause them to come back.

I really do want to fix that problem via locking: say taking i_shared_sem
inside mremap().  i_shared_sem is a very innermost lock and the ranking
with mmap_sem is all wrong.

For now, it would be sufficient to put a debug printk in there somewhere to
see if we are still getting Dickens pages.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/