Re: truncate_list_pages() BUG and confusion

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

Dave Hansen wrote:
> 
> in truncate_list_pages()
> 
>    failed = TryLockPage(page);
> 
> So, the page is always locked here.
> 
>    truncate_complete_page(page);
>          remove_inode_page(page);
>               if (!PageLocked(page))
>                  PAGE_BUG(page);
> 
>          page_cache_release(page);
>              calls __free_pages_ok(page, 0);
>                  if (PageLocked(page))
>                     BUG();
> 
> It is a BUG if the page is not locked in remove_inode_page() and also a
> bug if it IS locked in __free_pages_ok().  What am I missing?

the page_cache_release() in truncate_complete_page() is just dropping
the reference count against the page which is due to that page's
presence in the pagecache.  We just took it out, so we drop the reference.

Note that the caller of truncate_complete_page() also took a reference to
the page, and undoes that reference *after* unlocking the page.  This
additional reference will prevent __free_pages_ok() from being called
by truncate_complete_page().

> ksymoopsed output follows:
>
> kernel BUG at page_alloc.c:109!

Now how did you manage that?  Looks like someone re-locked
the page after truncate_list_pages unlocked it.

-