Re: [patch 2/13] remove pages from the LRU in __free_pages_ok()

[Andrew Morton <akpm@zip.com.au>]

Linus Torvalds wrote:
> 
> On Sun, 28 Jul 2002, Andrew Morton wrote:
> >
> > I don't think it can happen in 2.4.  In the truncate case,
> > the page is taken off the LRU by hand.  If do_flushpage()
> > failed then the buffers still have a ref on the page, which
> > is undone in shrink_cache(), inside pagemap_lru_lock.
> >
> > So, probably safe, but way too subtle.
> 
> That was by no means "subtle", it was all very much "design".

Well Rik and I missed it.  Not that this requires much subtlety ;)

> Just undo the broken patch by Rik, and we should all be home free again.

Problem is that the rmap VM doesn't perform swapout via pagetables.
It performs it via the LRU.

If someone is sleeping on a pagefault against a mmapped file, and a
truncate happens meanwhile, that page comes back as an anonymous
page.  It's not on the LRU any more so it has become unswappable.

Maybe we can check i_size in filemap_nopage and deliver a SIGBUS
or something.

For now we can go back to the explicit lru_cache_del() in truncate;
the little bit of unswappable memory is preferable to a deadlock
in TCP.  I'll send the patch after a bit of testing.

But (squeaky wheel), longer-term I want to make pagemap_lru_lock
irq safe.  This reduces contention on that lock by 30% (bringing
the total reduction for that patch series to around 98% - wiped off
the map).  And it fixes this problem.  And it allows us to move
pages between LRU lists at IO completion, if we want to do that.

-