Re: invalidate_inode_pages in 2.5.32/3

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

Chuck Lever wrote:
> 
> Andrew Morton wrote:
> 
> > Trond, there are very good reasons why it broke.  Those pages are
> > visible to the whole world via global data structures - both the
> > page LRUs and via the superblocks->inodes walk.  Those things exist
> > for legitimate purposes, and it is legitimate for async threads
> > of control to take a reference on those pages while playing with them.
> >
> > It just "happened to work" in earlier kernels.
> >
> > I suspect we can just remove the page_count() test from invalidate
> > and that will fix everything up.  That will give stronger invalidate
> > and anything which doesn't like that is probably buggy wrt truncate anyway.
> >
> > Could you test that?
> 
> removing that test from invalidate_inode_pages allows test6 to run to
> 
> completion.

OK, thanks.  I bet adding an lru_cache_drain() fixes it too.
 
> however, i don't see why the reference counts should be higher in
> 
> 2.5.32 than they were in 2.5.31.

Those pages are sitting in the cpu-local "to be added to the LRU soon"
queue, with their refcount elevated.

That queue really only makes sense for SMP, but it's enabled on UP so
we pick up any weird effects.  Voila.

>  is there a good way to test that
> these pages do not become orphaned?

Not that I know of - just run the test for ages and see if the box
runs out of memory.