On 02.07.25 12:10, Sergey Senozhatsky wrote:

On (25/07/02 10:25), David Hildenbrand wrote:

quoted

On 02.07.25 10:11, Sergey Senozhatsky wrote:

quoted

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

                       ^^ 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 -- balloon implements isolation as one would expect it 
(disallow freeing while isolated).

quoted

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.

Well, it's confusing, as we have MM compaction (-> migration) and 
apparently zs_compact.

I'll try to clarify that we are talking about isolation for page 
migration purposes.

-- 
Cheers,

David / dhildenb