[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190128130709.GJ18811@dhcp22.suse.cz>
Date: Mon, 28 Jan 2019 14:07:09 +0100
From: Michal Hocko <mhocko@...nel.org>
To: David Hildenbrand <david@...hat.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...hsingularity.net>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
Jan Kara <jack@...e.cz>,
Andrea Arcangeli <aarcange@...hat.com>,
Dominik Brodowski <linux@...inikbrodowski.net>,
Matthew Wilcox <willy@...radead.org>,
Vratislav Bendel <vbendel@...hat.com>,
Rafael Aquini <aquini@...hat.com>
Subject: Re: [PATCH RFC] mm: migrate: don't rely on PageMovable() of newpage
after unlocking it
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
Powered by blists - more mailing lists