> On Thu, 2008-06-12 at 19:13 -0700, Andrew Morton wrote:
>> On Fri, 13 Jun 2008 10:44:44 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>>
>>> This is reproducer of panic. "quick fix" is attached.
>> Thanks - I put that in
>>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.26-rc5/2.6.26-rc5-mm...
>>
>>> But I think putback_lru_page() should be re-designed.
>> Yes, it sounds that way.
>
> Here's a proposed replacement patch that reworks putback_lru_page()
> slightly and cleans up the call sites. I still want to balance the
> get_page() in isolate_lru_page() with a put_page() in putback_lru_page()
> for the primary users--vmscan and page migration. So, I need to drop
> the lock before the put_page() when handed a page with null mapping and
> a single reference count as the page will be freed on put_page() and a
> locked page would bug out in free_pages_check()/bad_page().
>
> Lee
>
> PATCH fix page unlocking protocol for putback_lru_page()
>
> Against: 2.6.26-rc5-mm3
>
> Replaces Kame-san's hotfix:
> fix-double-unlock_page-in-2626-rc5-mm3-kernel-bug-at-mm-filemapc-575.patch
>
> Applies at end of vmscan/unevictable/mlock series to avoid patch conflicts.
>
> 1) modified putback_lru_page() to drop page lock only if both page_mapping()
> NULL and page_count() == 1 [rather than VM_BUG_ON(page_count(page) != 1].
> I want to balance the put_page() from isolate_lru_page() here for vmscan
> and, e.g., page migration rather than requiring explicit checks of the
> page_mapping() and explicit put_page() in these areas. However, the page
> could be truncated while one of these subsystems holds it isolated from
> the LRU. So, need to handle this case. Callers of putback_lru_page()
> need to be aware of this and only call it with a page with NULL
> page_mapping() when they will no longer reference the page afterwards.
> This is the case for vmscan and page migration.
>
> 2) m[un]lock_vma_page() already will not be called for page with NULL
> mapping. Added VM_BUG_ON() to assert this.
>
> 3) modified clear_page_lock() to skip the isolate/putback shuffle for
> pages with NULL mapping, as they are being truncated/freed. Thus,
> any future callers of clear_page_lock() need not be concerned about
> the putback_lru_page() semantics for truncated pages.
>