Thread (138 messages) 138 messages, 5 authors, 2025-07-03

Re: [PATCH v1 03/29] mm/zsmalloc: drop PageIsolated() related VM_BUG_ONs

From: Lorenzo Stoakes <hidden>
Date: 2025-07-01 08:59:19
Also in: linux-fsdevel, linux-mm, linuxppc-dev, lkml, virtualization

On Tue, Jul 01, 2025 at 10:03:57AM +0200, David Hildenbrand wrote:
quoted
quoted
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 999b513c7fdff..7f1431f2be98f 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1719,8 +1719,6 @@ static bool zs_page_isolate(struct page *page, isolate_mode_t mode)
  	 * Page is locked so zspage couldn't be destroyed. For detail, look at
  	 * lock_zspage in free_zspage.
  	 */
-	VM_BUG_ON_PAGE(PageIsolated(page), page);
-
  	return true;
  }
@@ -1739,8 +1737,6 @@ static int zs_page_migrate(struct page *newpage, struct page *page,
  	unsigned long old_obj, new_obj;
  	unsigned int obj_idx;

-	VM_BUG_ON_PAGE(!zpdesc_is_isolated(zpdesc), zpdesc_page(zpdesc));
-
  	/* The page is locked, so this pointer must remain valid */
  	zspage = get_zspage(zpdesc);
  	pool = zspage->pool;
@@ -1811,7 +1807,6 @@ static int zs_page_migrate(struct page *newpage, struct page *page,

  static void zs_page_putback(struct page *page)
  {
-	VM_BUG_ON_PAGE(!PageIsolated(page), page);
  }
Can we just drop zs_page_putback from movable_operations() now this is empty?
Common code expects there to be a callback, and I don't want to change that.
Long-term I assume it will rather indicate a BUG if there is no putback
handler, not something we want to encourage.

Likely, once we rework that isolated pages cannot get freed here, we'd have
to handle stuff on the putback path (realize that the page can be freed and
free it) -- TODO for that is added in #12.
Ack thanks!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help