* [to-be-updated] mm-vmalloc-fix-vmap_purge_lock-livelock-under-memory-pressure.patch removed from -mm tree
@ 2026-09-26 16:35 Andrew Morton
0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2026-09-26 16:35 UTC (permalink / raw)
To: mm-commits, urezki, dev.jain, liuye, akpm
The quilt patch titled
Subject: mm: vmalloc: fix vmap_purge_lock livelock under memory pressure
has been removed from the -mm tree. Its filename was
mm-vmalloc-fix-vmap_purge_lock-livelock-under-memory-pressure.patch
This patch was dropped because an updated version will be issued
------------------------------------------------------
From: Ye Liu <liuye@kylinos.cn>
Subject: mm: vmalloc: fix vmap_purge_lock livelock under memory pressure
Date: Fri, 28 Aug 2026 17:17:53 +0800
The vmap_purge_lock mutex can be held for an extended period by
__purge_vmap_area_lazy() which calls flush_work() to wait for
purge_vmap_node workers while holding the lock. Under memory pressure,
those workers may themselves be blocked in direct reclaim trying to
acquire the same lock via the vmap_node_shrink_scan() shrinker callback,
creating a circular dependency that deadlocks the entire system.
Two places acquire vmap_purge_lock from paths that can be reached
during direct reclaim:
1. vmap_node_shrink_scan(): replace blocking guard(mutex) with
mutex_trylock(). This is a shrinker that only decays the vmap
pool and returns SHRINK_STOP without freeing memory; skipping a
decay cycle when the lock is contended is harmless and prevents
tasks from piling up on the mutex in the direct reclaim path.
2. reclaim_and_purge_vmap_areas(): replace mutex_lock() with
mutex_trylock(). This is called from the vmalloc allocation
overflow path; if trylock fails, another thread is already
purging and the allocator's retry will find freed space. The
notifier chain provides a fallback if the retry still fails.
Both trylock failures break the circular dependency: the lock holder's
flush_work() can complete because workers are no longer blocked on
vmap_purge_lock in the direct reclaim path.
Link: https://lore.kernel.org/20260828091753.299295-1-ye.liu@linux.dev
Fixes: 7679ba6b36db ("mm: vmalloc: add a shrinker to drain vmap pools")
Signed-off-by: Ye Liu <liuye@kylinos.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Suggested-by: Uladzislau Rezki <urezki@gmail.com>
Suggested-by: Dev Jain <dev.jain@arm.com>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
mm/vmalloc.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
--- a/mm/vmalloc.c~mm-vmalloc-fix-vmap_purge_lock-livelock-under-memory-pressure
+++ a/mm/vmalloc.c
@@ -2452,7 +2452,8 @@ static bool __purge_vmap_area_lazy(unsig
static void reclaim_and_purge_vmap_areas(void)
{
- mutex_lock(&vmap_purge_lock);
+ if (!mutex_trylock(&vmap_purge_lock))
+ return;
purge_fragmented_blocks_allcpus();
__purge_vmap_area_lazy(ULONG_MAX, 0, true);
mutex_unlock(&vmap_purge_lock);
@@ -5534,10 +5535,20 @@ vmap_node_shrink_scan(struct shrinker *s
{
struct vmap_node *vn;
- guard(mutex)(&vmap_purge_lock);
+ /*
+ * This shrinker is invoked from direct reclaim where memory
+ * pressure is already high. Blocking on vmap_purge_lock here
+ * can deadlock the system: the lock holder may be blocked in
+ * flush_work() waiting for a worker that is stuck in this same
+ * reclaim path trying to acquire the same lock. Use trylock
+ * to avoid this; skipping a pool decay cycle is harmless.
+ */
+ if (!mutex_trylock(&vmap_purge_lock))
+ return SHRINK_STOP;
for_each_vmap_node(vn)
decay_va_pool_node(vn, true);
+ mutex_unlock(&vmap_purge_lock);
return SHRINK_STOP;
}
_
Patches currently in -mm which might be from liuye@kylinos.cn are
tools-mm-page_owner_sort-fix-sort-option-being-silently-ignored.patch
tools-mm-page_owner_sort-add-module-name-sort-cull-filter-support.patch
tools-mm-page_owner_sort-show-available-sort-keys-in-usage-text.patch
mm-oom_kill-remove-unreachable-__gfp_thisnode-check-in-constrained_alloc.patch
mm-oom_kill-proc-replace-magic-number-1000-with-oom_score_adj_max.patch
mm-page_table_check-add-explicit-pmd_none-check-in-pte_clear_range.patch
mm-vmalloc-group-xa_init-with-vbq-field-initializations.patch
mm-vmalloc-extract-vmap_insert_free_area-helper.patch
mm-vmalloc-extract-show_busy_info-from-vmalloc_info_show.patch
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-09-26 16:36 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-26 16:35 [to-be-updated] mm-vmalloc-fix-vmap_purge_lock-livelock-under-memory-pressure.patch removed from -mm tree Andrew Morton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.