* [PATCH v2] zsmalloc: return -EBUSY for zspage migration lock contention
@ 2026-03-19 3:07 Hui Zhu
2026-03-19 3:24 ` Sergey Senozhatsky
0 siblings, 1 reply; 2+ messages in thread
From: Hui Zhu @ 2026-03-19 3:07 UTC (permalink / raw)
To: Minchan Kim, Sergey Senozhatsky, Andrew Morton, linux-mm,
linux-kernel
Cc: teawater
From: teawater <zhuhui@kylinos.cn>
movable_operations::migrate_page() should return an appropriate error
code for temporary migration failures so the migration core can handle
them correctly.
zs_page_migrate() currently returns -EINVAL when zspage_write_trylock()
fails. That path reflects transient lock contention, not invalid input,
so -EINVAL is clearly wrong.
However, -EAGAIN is also inappropriate here: the zspage's reader-lock
owner may hold the lock for an unbounded duration due to slow
decompression. Since migration retries are bounded by
NR_MAX_MIGRATE_PAGES_RETRY and performed with virtually no delay between
attempts, there is no guarantee the lock will be released in time for a
retry to succeed. -EAGAIN implies "try again soon", which does not hold
in this case.
Return -EBUSY instead, which more accurately conveys that the resource
is occupied and migration cannot proceed at this time.
Changelog:
v2:
According to the comments of Sergey Senozhatsky, change from -EAGAIN to
-EBUSY and add comments.
Signed-off-by: teawater <zhuhui@kylinos.cn>
---
mm/zsmalloc.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 2c1430bf8d57..db42ec4ffcfa 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1727,7 +1727,19 @@ static int zs_page_migrate(struct page *newpage, struct page *page,
if (!zspage_write_trylock(zspage)) {
spin_unlock(&class->lock);
write_unlock(&pool->lock);
- return -EINVAL;
+ /*
+ * Return -EBUSY but not -EAGAIN: the zspage's reader-lock
+ * owner may hold the lock for an unbounded duration due to a
+ * slow decompression.
+ * Since migration retries are bounded by
+ * NR_MAX_MIGRATE_PAGES_RETRY and performed with virtually no
+ * delay between attempts, there is no guarantee the lock will
+ * be released in time for a retry to succeed.
+ * -EAGAIN implies "try again soon", which does not hold here.
+ * -EBUSY more accurately conveys "resource is occupied,
+ * migration cannot proceed".
+ */
+ return -EBUSY;
}
/* We're committed, tell the world that this is a Zsmalloc page. */
--
2.43.0
^ permalink raw reply related [flat|nested] 2+ messages in thread* Re: [PATCH v2] zsmalloc: return -EBUSY for zspage migration lock contention
2026-03-19 3:07 [PATCH v2] zsmalloc: return -EBUSY for zspage migration lock contention Hui Zhu
@ 2026-03-19 3:24 ` Sergey Senozhatsky
0 siblings, 0 replies; 2+ messages in thread
From: Sergey Senozhatsky @ 2026-03-19 3:24 UTC (permalink / raw)
To: Hui Zhu, Andrew Morton
Cc: Minchan Kim, Sergey Senozhatsky, linux-mm, linux-kernel, teawater
On (26/03/19 11:07), Hui Zhu wrote:
> movable_operations::migrate_page() should return an appropriate error
> code for temporary migration failures so the migration core can handle
> them correctly.
>
> zs_page_migrate() currently returns -EINVAL when zspage_write_trylock()
> fails. That path reflects transient lock contention, not invalid input,
> so -EINVAL is clearly wrong.
>
> However, -EAGAIN is also inappropriate here: the zspage's reader-lock
> owner may hold the lock for an unbounded duration due to slow
> decompression. Since migration retries are bounded by
> NR_MAX_MIGRATE_PAGES_RETRY and performed with virtually no delay between
> attempts, there is no guarantee the lock will be released in time for a
> retry to succeed. -EAGAIN implies "try again soon", which does not hold
> in this case.
>
> Return -EBUSY instead, which more accurately conveys that the resource
> is occupied and migration cannot proceed at this time.
>
> Changelog:
> v2:
> According to the comments of Sergey Senozhatsky, change from -EAGAIN to
> -EBUSY and add comments.
I assume this Changelog was supposed to be under "---".
> + /*
> + * Return -EBUSY but not -EAGAIN: the zspage's reader-lock
> + * owner may hold the lock for an unbounded duration due to a
> + * slow decompression.
^^^ or reader-lock owner preemption
> + * Since migration retries are bounded by
> + * NR_MAX_MIGRATE_PAGES_RETRY and performed with virtually no
> + * delay between attempts, there is no guarantee the lock will
> + * be released in time for a retry to succeed.
> + * -EAGAIN implies "try again soon", which does not hold here.
> + * -EBUSY more accurately conveys "resource is occupied,
> + * migration cannot proceed".
> + */
> + return -EBUSY;
> }
Otherwise,
Acked-by: Sergey Senozhatsky <senozhatsky@chromium.org>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-03-19 3:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-19 3:07 [PATCH v2] zsmalloc: return -EBUSY for zspage migration lock contention Hui Zhu
2026-03-19 3:24 ` Sergey Senozhatsky
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox