[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ugm7j66msq2w2hd3jg3thsxd2mv7vudozal3nblnfemclvut64@yp7d6vgesath>
Date: Wed, 2 Jul 2025 19:10:34 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: David Hildenbrand <david@...hat.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-doc@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, virtualization@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, Jonathan Corbet <corbet@....net>,
Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>, Christophe Leroy <christophe.leroy@...roup.eu>,
Jerrin Shaji George <jerrin.shaji-george@...adcom.com>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Michael S. Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
Eugenio Pérez <eperezma@...hat.com>, Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, Zi Yan <ziy@...dia.com>,
Matthew Brost <matthew.brost@...el.com>, Joshua Hahn <joshua.hahnjy@...il.com>,
Rakie Kim <rakie.kim@...com>, Byungchul Park <byungchul@...com>,
Gregory Price <gourry@...rry.net>, Ying Huang <ying.huang@...ux.alibaba.com>,
Alistair Popple <apopple@...dia.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>,
Mike Rapoport <rppt@...nel.org>, Suren Baghdasaryan <surenb@...gle.com>,
Michal Hocko <mhocko@...e.com>, "Matthew Wilcox (Oracle)" <willy@...radead.org>,
Minchan Kim <minchan@...nel.org>, Brendan Jackman <jackmanb@...gle.com>,
Johannes Weiner <hannes@...xchg.org>, Jason Gunthorpe <jgg@...pe.ca>,
John Hubbard <jhubbard@...dia.com>, Peter Xu <peterx@...hat.com>, Xu Xin <xu.xin16@....com.cn>,
Chengming Zhou <chengming.zhou@...ux.dev>, Miaohe Lin <linmiaohe@...wei.com>,
Naoya Horiguchi <nao.horiguchi@...il.com>, Oscar Salvador <osalvador@...e.de>,
Rik van Riel <riel@...riel.com>, Harry Yoo <harry.yoo@...cle.com>,
Qi Zheng <zhengqi.arch@...edance.com>, Shakeel Butt <shakeel.butt@...ux.dev>
Subject: Re: [PATCH v1 12/29] mm/zsmalloc: stop using __ClearPageMovable()
On (25/07/02 10:25), David Hildenbrand wrote:
> On 02.07.25 10:11, Sergey Senozhatsky wrote:
> > On (25/06/30 14:59), David Hildenbrand wrote:
> > [..]
> > > static int zs_page_migrate(struct page *newpage, struct page *page,
> > > @@ -1736,6 +1736,13 @@ static int zs_page_migrate(struct page *newpage, struct page *page,
> > > unsigned long old_obj, new_obj;
> > > unsigned int obj_idx;
> > > + /*
> > > + * TODO: nothing prevents a zspage from getting destroyed while
> > > + * isolated: we should disallow that and defer it.
> > > + */
> >
> > Can you elaborate?
>
> We can only free a zspage in free_zspage() while the page is locked.
>
> After we isolated a zspage page for migration (under page lock!), we drop
^^ a physical page? (IOW zspage chain page?)
> the lock again, to retake the lock when trying to migrate it.
>
> That means, there is a window where a zspage can be freed although the page
> is isolated for migration.
I see, thanks. Looks somewhat fragile. Is this a new thing?
> While we currently keep that working (as far as I can see), in the future we
> want to remove that support from the core.
Maybe comment can more explicitly distinguish zspage isolation and
physical page (zspage chain) isolation? zspages can get isolated
for compaction (defragmentation), for instance, which is a different
form of isolation.
> So what probably needs to be done is, checking in free_zspage(), whether the
> page is isolated. If isolated, defer freeing to the putback/migration call.
Perhaps.
Powered by blists - more mailing lists