On 02.07.25 10:11, Sergey Senozhatsky wrote:

On (25/06/30 14:59), David Hildenbrand wrote:
[..]

quoted

  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 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.

While we currently keep that working (as far as I can see), in the 
future we want to remove that support from the core.

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.

That way, it will be clear who the current owner of an object is 
(isolation makes mm core the owner, while putback returns ownership), 
and prepare for some pages to be migrated to have a permanently frozen 
refcount (esp PageOffline pages without any refcount).

-- 
Cheers,

David / dhildenb