Re: truncate_list_pages() page lock confusion and BUG

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

Dave Hansen wrote:
> 
> I'm getting BUG()s from page_alloc.c:109 in 2.5.6-pre2
> 
> truncate_list_pages() contains
> 
> failed = TryLockPage(page);
> 
> The page should always be locked when I get past there
> 
> shortly after this, truncate_complete_page() can be called
> 
> truncate_complete_page() calls:
>          remove_inode_page(page);
>               if (!PageLocked(page))
>                  PAGE_BUG(page);
> followed immediately by
>          page_cache_release(page);
>              calls __free_pages_ok(page, 0);
>                  if (PageLocked(page))
>                     BUG();
> 
> So, it appears that when truncate_complete_page() is called, it is a BUG
> if the page is unlocked in remove_inode_page(), or locked in
> page_cache_release().   What am I missing?  Actual bug follows:
> 

The page should not be actually freed by truncate_complete_page().
See how truncate_list_pages() has bumped its refcount?

If the page is successfully truncated then the actual freeing
occurs in the page_cache_release() in truncate_list_pages(),
after the page has been unlocked.

Looks like the page refcount has suffered an extra decrement
somewhere.  You're hitting this on the not-very-tested 
generic_file_write() error path.  But it all looks to be OK.


2.5.6 is awfully ancient.

-