Re: objrmap-core-1 (rmap removal for file mappings to avoid 4:4 in <=16G machines)

[Andrew Morton <akpm@osdl.org>]

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.