From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC5C141D219 for ; Wed, 12 Aug 2026 10:06:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786529214; cv=none; b=jiHLM25rXUP+KRrCWinQql7Zf9nRE4PPE178VJS3aUxnJAkePXJK/H/R592y86SovQKtbEay0XIHIYLK6obp+OZjriAAp/rfg9bqO9Q6RBA4V2I2biY8FQhIb3j+/tQkU0qnYOEROd7D2EadgJxUGHJP/+xayYO54veqVD2L3sw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786529214; c=relaxed/simple; bh=Tq3ig59XOSZiJUrUHY7Jr+5SU4PtrrrGUgkQ/Yrj6Yw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RjgPX+wggcrBrHdTwWamIz9dkV3G2QgjB1QT+Hg/+agGQNzWJRwZdbqN3cgphZCxWVaz8Y63teIJlPSsfePXscu/ad8e2med0ppfa4WfLo+jSSilqeR0VqMM1gS5s0st5SejU0XloEANZcBpLwrXHUlSJzfFyRJpjVBrgk771A8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=K2+9qNFW; arc=none smtp.client-ip=115.124.30.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="K2+9qNFW" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1786529202; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=whbGaMoThWv2dBW7Kxk5/d4zBPlY4UqC7T4kOF653JI=; b=K2+9qNFWK+lKOBQAmxHSn91VpQHr6cvkRhvwRR6NZNrmwtS1JjJqbYmOi04CPEzrS3aoM740KLnv+bqH5WgXapxIircPFmmI+faV0g4gL3DzMjKhZfEcFKDBBu/mFF3Mi+vnQnVml2qnTK3Lc3JcQpuNb85bogCFSKeMerNoQeI= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R261e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0X8rG3jP_1786529198; Received: from 30.74.144.118(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X8rG3jP_1786529198 cluster:ay36) by smtp.aliyun-inc.com; Wed, 12 Aug 2026 18:06:40 +0800 Message-ID: <9ac2eb18-1b8d-49b1-bbf5-757c4164c566@linux.alibaba.com> Date: Wed, 12 Aug 2026 18:06:38 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/mglru: fix and remove redundant unevictable folio handling To: kasong@tencent.com, linux-mm@kvack.org Cc: Andrew Morton , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Oleksandr Natalenko , Suleiman Souhlal , "Jan Alexander Steffens (heftig)" , Yu Zhao , Steven Barrett , Brian Geffon , Kairui Song , linux-kernel@vger.kernel.org References: <20260811-mglru-mlock-fix-v1-1-8b2321d0e1d3@tencent.com> From: Baolin Wang In-Reply-To: <20260811-mglru-mlock-fix-v1-1-8b2321d0e1d3@tencent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/11/26 5:40 PM, Kairui Song via B4 Relay wrote: > From: Kairui Song > > sort_folio() has a shortcut for moving folios that are no longer > evictable but are still sitting on a generation list. However, this > shortcut is buggy. It does not follow the PG_lru usage convention, > and it has a more serious issue. > > Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that > folio->lru can be reused to hold folio->mlock_count (see the comment in > lruvec_init()). Hence lruvec_add_folio() skips the list_add() for them, > and every other place that turns a folio unevictable initialises > mlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and > __mlock_new_folio() set it to !!folio_test_mlocked(folio). > sort_folio() sets nothing, and the lru_gen_del_folio() right above it > may have already poisoned folio->lru via list_del(), so mlock_count > ends up aliasing LIST_POISON2, which reads as 0x122, i.e. 290. The > result is user visible. On munlock, __munlock_folio() decrements that > bogus count, finds it still non-zero and bails out before clearing > PG_mlocked, so the folio remains unevictable and the Mlocked > accounting stays inflated until the folio is freed. > > The shortcut also touches the LRU flags in the wrong order. It calls > lru_gen_del_folio() while PG_lru is still set, so a concurrent > folio_test_clear_lru() (e.g. compaction, folio_isolate_lru()) can succeed > on a folio that has already been taken off the generation list, may > lead to unexpected behavior. The generic path gets this right: > isolate_folio() clears PG_lru first, so a racing isolator loses the > atomic and bails. > > And the shortcut is redundant. A folio left on the generation list is > picked up by isolate_folio(), shrink_folio_list() sends it to > activate_locked on the !folio_evictable() check, and evict_folios() > then hands it to folio_putback_lru(), which sets PG_unevictable and > counts UNEVICTABLE_PGCULLED from lru_add(), with mlock_count > initialised properly. > > There is no performance concern either: such a folio goes through this > once, and then it is off the generation lists for good, since > lru_gen_add_folio() refuses unevictable folios. > > So just remove the shortcut. This consolidates unevictable handling in > the generic path, and makes maintenance easier. > > Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") > Signed-off-by: Kairui Song > --- Good catch. Make sense to me. Reviewed-by: Baolin Wang