From 0ee331db893d515c88f65a6bf3f72ff2cc6fba4a Mon Sep 17 00:00:00 2001 From: Anthony Date: Tue, 13 Oct 2026 22:25:42 +0200 Subject: [PATCH] binder: don't relock after LRU_REMOVED_RETRY on Linux >= 6.13 Since 6.13 the list_lru walker reacquires the lock itself after LRU_REMOVED_RETRY. Taking it in the callback makes the next lock_list_lru_of_memcg() spin forever, leaving kswapd at 100% CPU in binder_shrink_scan(). --- binder/binder_alloc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/binder/binder_alloc.c b/binder/binder_alloc.c index 9afc7bb..5113690 100644 --- a/binder/binder_alloc.c +++ b/binder/binder_alloc.c @@ -1048,8 +1048,16 @@ enum lru_status binder_alloc_free_page(struct list_head *item, trace_binder_unmap_kernel_end(alloc, index); - spin_lock(lock); mutex_unlock(&alloc->mutex); +#if (LINUX_VERSION_CODE < KERNEL_VERSION(6, 13, 0) && \ + !defined(RHEL_10_1_BACKPORTS)) + /* Before 6.13, LRU_REMOVED_RETRY means the lock was reacquired. */ + spin_lock(lock); +#endif + /* + * Since 6.13 the walker relocks itself after LRU_REMOVED_RETRY; + * taking the lock here would make it spin forever (kswapd at 100%). + */ return LRU_REMOVED_RETRY; err_mmap_read_lock_failed: