From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by kanga.kvack.org (Postfix) with ESMTP id DC83E6B0074 for ; Mon, 9 Jun 2014 08:02:07 -0400 (EDT) Received: by mail-pd0-f171.google.com with SMTP id y13so4726951pdi.16 for ; Mon, 09 Jun 2014 05:02:07 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com. [42.120.133.146]) by mx.google.com with ESMTP id xd9si2096830pab.19.2014.06.09.05.02.04 for ; Mon, 09 Jun 2014 05:02:07 -0700 (PDT) Reply-To: "=?GBK?B?1cW+siizpLnIKQ==?=" From: "=?GBK?B?1cW+siizpLnIKQ==?=" Subject: Re: 3.15-rc8 mm/filemap.c:202 BUG Date: Mon, 09 Jun 2014 20:01:54 +0800 Message-ID: <013901cf83da$9b8d4670$d2a7d350$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01CF841D.A9B6EF10" Content-Language: zh-cn Sender: owner-linux-mm@kvack.org List-ID: To: 'Hugh Dickins' Cc: 'Sasha Levin' , 'Andrew Morton' , "'Kirill A. Shutemov'" , 'Konstantin Khlebnikov' , 'Dave Jones' , linux-mm@kvack.org, 'Linus Torvalds' This is a multipart message in MIME format. ------=_NextPart_000_013A_01CF841D.A9B6EF10 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi Hugh On Fri, Jun 6, 2014 at 4:05 PM, Hugh Dickins 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 ------=_NextPart_000_013A_01CF841D.A9B6EF10 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi =
Hugh
 
On Fri, Jun 6, 2014 at 4:05 PM, Hugh =
Dickins <hughd@google.com> 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

/*<= /p>

    = * 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=3D=3DNULL 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) {

   &nb= sp;   VM_BUG_ON_PAGE(PageAnon(page), = page);

   &nb= sp;   if (page_has_private(page)) {

   &nb= sp;       = try_to_free_buffers(page);

   &nb= sp;       goto = uncharge;

   &nb= sp;   }

   &nb= sp;   goto skip_unmap;

    = }

 

    = /* Establish migration ptes or remove ptes */

    = try_to_unmap(page, = TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS);

<= p class=3DMsoNormal align=3Dleft = style=3D'text-align:left;text-autospace:none'> 

skip_unmap:

    = if (!page_mapped(page))

   &nb= sp;   rc =3D move_to_new_page(newpage, page, remap_swapcache, = mode);

 

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

 

    = mapping =3D page_mapping(page);

    = if (!mapping)

   &nb= sp;   rc =3D migrate_page(mapping, newpage, page, = mode);

 

 

    = if (!mapping) {

   &nb= sp;   /* Anonymous page without mapping = */

   &nb= sp;   if (page_count(page) !=3D = expected_count)

   &nb= sp;       return = -EAGAIN;

   &nb= sp;   return MIGRATEPAGE_SUCCESS;

    = }

 

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

Is that = right?

 

Thanks

Hillf

 

------=_NextPart_000_013A_01CF841D.A9B6EF10-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org