From: Hugh Dickins <hughd@google.com>
To: hillf.zj@alibaba-inc.com
Cc: Sasha Levin <sasha.levin@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Dave Jones <davej@redhat.com>,
linux-mm@kvack.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: 3.15-rc8 mm/filemap.c:202 BUG
Date: Mon, 9 Jun 2014 11:52:19 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.11.1406091150100.5896@eggly.anvils> (raw)
In-Reply-To: <013901cf83da$9b8d4670$d2a7d350$@alibaba-inc.com>
On Mon, 9 Jun 2014, hillf wrote:
> 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
>
> /*
> * 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.
I don't think I'd say that an orphaned page cannot be migrated; but
I do agree that it's better just to try free the page than migrate it.
> */
> 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);
(There is an inefficiency here: it would better check page_mapped(page)
before calling try_to_unmap(), which would save getting i_mmap_mutex
unnecessarily. But that's an aside, it's not wrong as it stands.)
>
> 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!
Why the exclamation mark? We have just tried to unmap it, so no
surprise that the page is now not mapped. As to "no mapping": we
hold the page lock, so it's a bug if the state of "page->mapping"
has changed since we tested it above.
>
> mapping = page_mapping(page);
> if (!mapping)
> rc = migrate_page(mapping, newpage, page, mode);
You need to check the way page_mapping(page) works: it doesn't
simply return page->mapping, but supplies swap_address_space if
PageSwapCache is set, or otherwise NULL on an anonymous page.
I think your "no mapping" above amounts to swapless anonymous.
>
>
> 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?
Nothing wrong with it that I see: the truncated file !page->mapping
case has already been skipped in the "Corner case handling" block,
though it would not worry me if an orphan page did reach here - the
page count check will still refuse to migrate "unexplainable" pages.
Hugh
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-06-09 18:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-09 12:01 张静(长谷)
2014-06-09 18:52 ` Hugh Dickins [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-06-03 4:21 Dave Jones
2014-06-03 9:11 ` Konstantin Khlebnikov
2014-06-03 23:11 ` Hugh Dickins
2014-06-03 23:41 ` Dave Jones
2014-06-04 12:33 ` Sasha Levin
2014-06-06 23:05 ` Hugh Dickins
2014-06-06 23:16 ` Linus Torvalds
2014-06-06 23:21 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.11.1406091150100.5896@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=hillf.zj@alibaba-inc.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=koct9i@gmail.com \
--cc=linux-mm@kvack.org \
--cc=sasha.levin@oracle.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox