Re: [PATCH] __free_pages_ok oops

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Feb 07, 2002 at 02:31:33PM -0800, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> > 
> > > Good to hear.  But what about the weird corner-case in truncate_complete_page(),
> > > where a mapped page is not successfully released, and is converted into
> > > an anon buffercache page?  It seems that a combination of sendfile
> > > and truncate could result in one of those pages being subject to
> > > final release in BH context?
> > 
> > Such a page is not in the lru so it doesn't matter.
> 
> static void truncate_complete_page(struct page *page)
> {
>         /* Leave it on the LRU if it gets converted into anonymous buffers */
>         if (!page->buffers || do_flushpage(page, 0))
>                 lru_cache_del(page);
> 
> If the page has buffers, and do_flushpage() fails, what happens?
> 
> > As said in the previous email, from another point of view, the only
> > thing that can be still in the lru during __free_pages_ok is an
> > anonymous page. truncate_complete_page cannot run on an anonymous page.
> > Anonymous pages cannot be truncated.
> 
> truncate_complete_page() can, in rare circumstances, take a page
> which was in both the pagecache and on LRU, and leave it purely
> on LRU.  And because that page *used* to be in pagecache, it
> could be undergoing sendfile.
> 
> Or I'm missing something.  Did something change?

as said in the previous email that becomes a buffercache mapped in
userspace, with refcount > 1 (unfreeable from the vm side), so the
__free_page from irq will do nothing (it will only decrease the refcount
of 1 unit, and then the page will be released by the vm). If the
refcount was 1 instead, then it means the page wasn't in the lru in the
first place and so the check won't trigger either.

Only truly anonymous pages (not ex pagecache, later become buffercache)
can trigger such PageLRU check in __free_pages_ok.  Infact if it wasn't
the case all the kernels before 2.4.1x would been broken.

Andrea