From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (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 080692F3C18 for ; Thu, 13 Aug 2026 00:45:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.111 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786581962; cv=none; b=PqiwogsOSYhwWeXIWE61Gx6YDxfNx8RHqDlR2hTc2J743wJDV+UmA5OUAiuWtkMca7zSgvspRtmZB7JgTDKszDRJ+j786oLL882vHyQxr0a04DcrK/WC+LXp8i7lUxul/G4Sqb2jo4nOLPoQmdviFmegPA1+w4TDiCnkUPF6TK8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786581962; c=relaxed/simple; bh=fGROtQ16DZ+jpgKNR+ud/pcyTqQNfhVqO51vlDus/pE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pfbQAd9MREGe7mw2DcPSNalIRsRdTXR6BkAMtpE+mKxZt2L9jH7AaAnpSrMbsBtTnOQfwFRq0XnY5XrFPS2cWAZgDedzvxWXz/KCmk/grBs39TeBtQkTsqV1g2/rzAAsBVjk20ZkarMmf99fHAf2ty++keDinueO8DqJv50syUs= 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=ZUWd1jo4; arc=none smtp.client-ip=115.124.30.111 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="ZUWd1jo4" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1786581954; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=QRT8RrGVuqSxCv/yXXyh/unIGYLOWUOs5uKYEzFW/BE=; b=ZUWd1jo4hteDbt8LLJPiyonCN3Ifbam+V8qt5ynzxdRB6F6OmbwucvLFgLXCiysmM62Xhbdv28OOeGtVfjECAyBkSLXOVb9QpSs9zQrFwVG7SxNGTyvBO4vUilK1X2wSaa57Qv2njwfkmok/Zl1fK0+CPFIuMl+KCHUP63MGltE= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045098064;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=20;SR=0;TI=SMTPD_---0X8sfoOn_1786581952; Received: from 30.74.144.111(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X8sfoOn_1786581952 cluster:ay36) by smtp.aliyun-inc.com; Thu, 13 Aug 2026 08:45:52 +0800 Message-ID: <6fbd52ec-e16b-48a7-a4cd-eb495bdd43d3@linux.alibaba.com> Date: Thu, 13 Aug 2026 08:45:51 +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: Kairui Song Cc: linux-mm@kvack.org, 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 , linux-kernel@vger.kernel.org References: <20260811-mglru-mlock-fix-v1-1-8b2321d0e1d3@tencent.com> <9ac2eb18-1b8d-49b1-bbf5-757c4164c566@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/12/26 8:28 PM, Kairui Song wrote: > On Wed, Aug 12, 2026 at 6:06 PM Baolin Wang > wrote: >> >> 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 > > Hi Baolin > > Thank you very mcuh for the review! > > I just sent a V2 here: > https://lore.kernel.org/linux-mm/20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com/T/#u > > This is a bit different, idea is still the same but I changed the > code, since the patch is very small so it's basically a rewrite, hence > I didn't include this review by. Can you help have a look at v2 as > well? Sure. Thanks for the fix.