Re: 3.15-rc8 mm/filemap.c:202 BUG

["张静(长谷)" <hillf.zj@xxxxxxxxxxxxxxx>]

Hi Hugh

On Fri, Jun 6, 2014 at 4:05 PM, Hugh Dickins <hughd@xxxxxxxxxx> wrote:
>
> Though I'd wanted to see the remove_migration_pte oops as a key to the
> page_mapped bug, my guess is that they're actually independent.

> 

In the 3.15-rc8 tree, along the migration path

/*

    * Corner case handling:

    * 1. When a new swap-cache page is read into, it is added to the LRU

    * and treated as swapcache but it has no rmap yet.

    * Calling try_to_unmap() against a page->mapping==NULL page will

    * trigger a BUG.  So handle it here.

    * 2. An orphaned page (see truncate_complete_page) might have

    * fs-private metadata. The page can be picked up due to memory

    * offlining.  Everywhere else except page reclaim, the page is

    * invisible to the vm, so the page can not be migrated.  So try to

    * free the metadata, so the page can be freed.

    */

    if (!page->mapping) {

       VM_BUG_ON_PAGE(PageAnon(page), page);

       if (page_has_private(page)) {

           try_to_free_buffers(page);

           goto uncharge;

       }

       goto skip_unmap;

    }

 

    /* Establish migration ptes or remove ptes */

    try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);

 

skip_unmap:

    if (!page_mapped(page))

       rc = move_to_new_page(newpage, page, remap_swapcache, mode);

 

Here a page is migrated even not mapped and with no mapping!

 

    mapping = page_mapping(page);

    if (!mapping)

       rc = migrate_page(mapping, newpage, page, mode);

 

 

    if (!mapping) {

       /* Anonymous page without mapping */

       if (page_count(page) != expected_count)

           return -EAGAIN;

       return MIGRATEPAGE_SUCCESS;

    }

 

And seems a file cache page is treated in the way of Anon.

Is that right?

 

Thanks

Hillf