From: Michal Hocko <mhocko@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@techsingularity.net>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Jan Kara <jack@suse.cz>, Andrea Arcangeli <aarcange@redhat.com>,
Dominik Brodowski <linux@dominikbrodowski.net>,
Matthew Wilcox <willy@infradead.org>,
Vratislav Bendel <vbendel@redhat.com>,
Rafael Aquini <aquini@redhat.com>
Subject: Re: [PATCH RFC] mm: migrate: don't rely on PageMovable() of newpage after unlocking it
Date: Mon, 28 Jan 2019 14:07:09 +0100 [thread overview]
Message-ID: <20190128130709.GJ18811@dhcp22.suse.cz> (raw)
In-Reply-To: <20190128121609.9528-1-david@redhat.com>
On Mon 28-01-19 13:16:09, David Hildenbrand wrote:
[...]
> My theory:
>
> In __unmap_and_move(), we lock the old and newpage and perform the
> migration. In case of vitio-balloon, the new page will become
> movable, the old page will no longer be movable.
>
> However, after unlocking newpage, I think there is nothing stopping
> the newpage from getting dequeued and freed by virtio-balloon. This
> will result in the newpage
> 1. No longer having PageMovable()
> 2. Getting moved to the local list before finally freeing it (using
> page->lru)
Does that mean that the virtio-balloon can change the Movable state
while there are other users of the page? Can you point to the code that
does it? How come this can be safe at all? Or is the PageMovable stable
only under the page lock?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2019-01-28 13:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 12:16 [PATCH RFC] mm: migrate: don't rely on PageMovable() of newpage after unlocking it David Hildenbrand
2019-01-28 13:07 ` Michal Hocko [this message]
2019-01-28 13:14 ` David Hildenbrand
2019-01-28 13:21 ` Michal Hocko
2019-01-28 13:22 ` David Hildenbrand
2019-01-28 13:35 ` Michal Hocko
2019-01-28 14:38 ` David Hildenbrand
2019-01-28 14:53 ` Michal Hocko
2019-01-28 15:01 ` Rafael Aquini
2019-01-28 15:04 ` Rafael Aquini
2019-01-28 15:13 ` David Hildenbrand
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=20190128130709.GJ18811@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=david@redhat.com \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@dominikbrodowski.net \
--cc=mgorman@techsingularity.net \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=vbendel@redhat.com \
--cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).