[lkml]   [2002]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] __free_pages_ok oops
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))

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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.109 / U:6.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site