From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 3F0943E1228 for ; Wed, 12 Aug 2026 20:59:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786568393; cv=none; b=ZGCLNOCLGJrXvafDBZmxaRMv/Nh3UIEO0ujMQoaW8jghCDxwuRDNKug9axE+ZenWYa2rMo0wsB4BLSKMuwhfMBmIW4S6uAZ1BASQH8SXOc1TrxMAlpqUbsMY5QNcW7OL4fHKAsdwJkWC0xJQ/1YgQHsTXBSZ0S1l4dWYTJw6Lg0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786568393; c=relaxed/simple; bh=SZ/945/u3D2YqxpWH2XMDON4o3mz9+ctgMeXiaY7n0w=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=qUhbxLipHepEFN+ptp7xjC0k9sG0ggjukrxkMyrsaIiuUtcj94Gq3W1xtAL26KX6cHtsl4Eqa3r6kFTuaXUk2FsvwyE+EAvVKyuZeRleBRFax164QFNOqIyYCH08+tFx58YBA4lBJDim3FhDfsO2rhXA8Tm5OvcLvtSc+eokQ6Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=omo/IJPB; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="omo/IJPB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C0D41F000E9; Wed, 12 Aug 2026 20:59:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1786568391; bh=9HhQDV4TMS1IsLfsE2GhssqJQtN6BUemuKTL663tfbU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=omo/IJPBCvJE92c/rcnjZDz5GE2f57flieOy47UKYZSiTjBEwtf20puIX65y+2GsC 6qb+G8t5KVimug3Lyg97m/IgE5SK0Z6HoSxSFOm3W+c0qFX/E+NiLEAmoLeoAxQyne V+6+8NbbWJ0FrLyubvZp5Tu+1W5UTqb9xYTpuhbU= Date: Wed, 12 Aug 2026 13:59:50 -0700 From: Andrew Morton To: kasong@tencent.com Cc: Kairui Song via B4 Relay , linux-mm@kvack.org, 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 , Baolin Wang , Kairui Song , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/mglru: fix and remove redundant unevictable folio handling Message-Id: <20260812135950.232d9b326bf3630e8edf17ca@linux-foundation.org> In-Reply-To: <20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com> References: <20260812-mglru-mlock-fix-v2-1-a3fec5853c08@tencent.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 12 Aug 2026 20:22:39 +0800 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. Great, thanks. > Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") The above description makes me think -stable wants this. That ac35a4902374 is four years old makes me think that we can feed this in for 7.3-rc1. OK?