From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) (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 57B89282F13 for ; Thu, 13 Aug 2026 01:20:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.110 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786584014; cv=none; b=DwflwUSLeuIwlvGRYVdJNFZJnWcB8bfBNDc1MXbqtPem/4U48eo8OcEw2dQaLOakMRLwrzxPOzw2ApWhuUz+OEogSRivMX9n4ZL1h8F46dcVk8ItrwmbyPBeFXeBcvuulLkw7yzW+zUXLYqM5DuP7orQYpKKKSybDjdHHZ113dA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786584014; c=relaxed/simple; bh=uLHCreQY/ed0XIU/rL8K0lRqJ2feAVo6FogHLyhVq/Q=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=blhK9RNVloCQYcZeRed+MnPrKkwUPfD0oS8fS4Lx6nkGiFm9Gt3/3cCn+8FHtfUAJegW2JdQwd0KlctYCSxvUYQpx96ZafOXo8rdnibLxL+lbABXmJccgtZdK4tI7+T10a6/Wq2xrIzakE/P9PB5fRsTc9ym0bw9ZmpNnLkFSf4= 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=CZZ0k8lV; arc=none smtp.client-ip=115.124.30.110 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="CZZ0k8lV" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1786584003; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=ED8Tp9lm2QOcPjmMOrBKPEMtsi7PWnnaCdiDcnQCvuw=; b=CZZ0k8lVjKHkt63D7922v5qjOuTUCeFuLzEoba6xGTbn3L+8YUBAMIVG7seg3HUWoqbiEi5gu0Z7sexSQ57g5frMsyQObYxzAHfkdmjvdi3saiQoiBaAr5bPIOKUZKn+mt28y0FCROo9IjYaENN3xQ3LHAGXcvq5rC6O8BtJ5vQ= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R111e4;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_---0X8skQm4_1786584001; Received: from 30.74.144.111(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X8skQm4_1786584001 cluster:ay36) by smtp.aliyun-inc.com; Thu, 13 Aug 2026 09:20:01 +0800 Message-ID: Date: Thu, 13 Aug 2026 09:20:00 +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 v2] 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: <20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com> From: Baolin Wang In-Reply-To: <20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/12/26 8:22 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, > which may lead to unexpected behavior. > > So fix it by isolating them as common folios and letting the generic > shrink path cull them. This matches the classical LRU behavior, and > there should be no visible effect on the generic eviction or isolation > behavior. > > There is no performance concern either, such a folio goes through this > once, and then it is off the generation lists for good. > > Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") > Signed-off-by: Kairui Song > --- > Changes in v2: > - Proactively bypass MGLRU pid protection and lazy promotion to avoid > hot unevcitable folios staying on list for a long time. > - Link to v1: https://patch.msgid.link/20260811-mglru-mlock-fix-v1-1-8b2321d0e1d3@tencent.com > --- > mm/vmscan.c | 19 +++++-------------- > 1 file changed, 5 insertions(+), 14 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 3194da7dcc79..ca2b926520ea 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -4648,7 +4648,6 @@ void lru_gen_reparent_memcg(struct mem_cgroup *memcg, struct mem_cgroup *parent, > static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_control *sc, > int tier_idx) > { > - bool success; > int gen = folio_lru_gen(folio); > int type = folio_is_file_lru(folio); > int zone = folio_zonenum(folio); > @@ -4660,15 +4659,9 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c > > VM_WARN_ON_ONCE_FOLIO(gen >= MAX_NR_GENS, folio); > > - /* unevictable */ > - if (!folio_evictable(folio)) { > - success = lru_gen_del_folio(lruvec, folio, true); > - VM_WARN_ON_ONCE_FOLIO(!success, folio); > - folio_set_unevictable(folio); > - lruvec_add_folio(lruvec, folio); > - __count_vm_events(UNEVICTABLE_PGCULLED, delta); > - return true; > - } > + /* unevictable: let it through and the generic path will cull it */ > + if (!folio_evictable(folio)) > + return false; OK, returning false early in sort_folio() is better. Although I think mlocked folios won't stay in the LRU list for long, and shrink_folio_list() will also reject them anyway. > /* promoted */ > if (gen != lru_gen_from_seq(lrugen->min_seq[type])) { > @@ -4921,11 +4914,9 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec, > list_for_each_entry_safe_reverse(folio, next, &list, lru) { > DEFINE_MIN_SEQ(lruvec); > > - if (!folio_evictable(folio)) { > - list_del(&folio->lru); > - folio_putback_lru(folio); > + /* move_folios_to_lru() culls unevictable folios via folio_putback_lru() */ > + if (!folio_evictable(folio)) > continue; Yes. Still look good to me. So feel free to add: Reviewed-by: Baolin Wang