On (25/07/03 11:28), Sergey Senozhatsky wrote:

quoted

quoted

quoted

quoted

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

                       ^^ a physical page? (IOW zspage chain page?)

quoted

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?

No, it's been like that forever. And I was surprised that only zsmalloc
behaves that way

Oh, that makes two of us.

I sort of wonder if zs_page_migrate() VM_BUG_ON_PAGE() removal and
zspage check addition need to be landed outside of this series, as
a zsmalloc fixup.