From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-190.mta1.migadu.com [95.215.58.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AFC02AD2C for ; Thu, 20 Aug 2026 00:53:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.190 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787187225; cv=none; b=IZQ26WH+jHywCeaf1LPCEdQiEdEQ5Gf2CuFOuUrL5y+39IpSd9jWM2RVHViKgiO2bjzKuMuUpWamYdOCvahnnO9QMWzLY5HHm0HR1dKEUkJJK2CbdJim+4n5DPYMKcpxX2OcHgIijxfR6ACSfVyPIutBjZB6+ZiiBcSQ6l/oYkk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787187225; c=relaxed/simple; bh=5IsuarZfSd5llKVGh9q2wBsTwYfZwdg1wFWVV1JFi6c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BENNDoxCqdvfyiomWcvH3ziA2gPW/8IzdZpKim9WQillg25r+lbCDVk6ZwklaQT9yy+x/V7bchC1cqBwXL29XWlf4qLDQR6DRtdGDQ7uk0CDxNvm9TiH8IbiJd5I1xXaSXOxXBhZ7zsMRe44oQqVwd0hI1lHWmPYAG31cR2xYuE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=SXBOL+Vd; arc=none smtp.client-ip=95.215.58.190 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="SXBOL+Vd" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=5IsuarZfSd5llKVGh9q2wBsTwYfZwdg1wFWVV1JFi6c=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787187220; v=1; x=1787792020; b=SXBOL+VdiIb1J5uXt3vYlPcDd+SGdhvb79yMu4nPEOiK37coHBh4jdjDCqaAnAhu1oE3o1fQ bsbcKHIXVVgm7UsZNktSuOZtyUYT7dsAMtgPnQl2vkAKoLW06R27OJd3N9gIepYnfSvH1EO5sAJ yz2y0QvdeWFFZamh6VxSAU5I= X-Envelope-To: linux-kernel@vger.kernel.org Received: from localhost (3.112.29.171) by mta12.migadu.com with ESMTPS id 07c8e31ddffe1a8d; Thu, 20 Aug 2026 00:53:40 +0000 X-Mizu-Trace-ID: 07c8e31ddffe1a8d X-Migadu-Flow: FLOW_OUT Date: Thu, 20 Aug 2026 08:53:35 +0800 From: Baoquan He To: kasong@tencent.com Cc: linux-mm@kvack.org, Andrew Morton , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Shakeel Butt , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Chris Li , Baolin Wang , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Yu Zhao , Zi Yan , Qi Zheng , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Kairui Song Subject: Re: [PATCH 7/7] mm/mglru: improve code readability and harden folio_inc_gen Message-ID: References: <20260818-mglru-flags-cleanup-v1-0-8dbbdac0d28c@tencent.com> <20260818-mglru-flags-cleanup-v1-7-8dbbdac0d28c@tencent.com> 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-Disposition: inline In-Reply-To: <20260818-mglru-flags-cleanup-v1-7-8dbbdac0d28c@tencent.com> On 08/18/26 at 01:38pm, Kairui Song via B4 Relay wrote: > From: Kairui Song > > The helper should never be called for an off-list folio, and it always > expects the folio to be in the oldest generation before doing any > cmpxchg. Add a sanity check for the off-list case: if it is ever > violated, bail out and keep the folio flags untouched to minimize the > damage, instead of silently treating the folio as if it were in the > oldest generation and promoting it updating the flags to an unexpected > status. > > Also rename the variables to clearly distinguish the folio's current > gen from the oldest gen. > > Signed-off-by: Kairui Song > --- > mm/vmscan.c | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 7169cac60869..7e3ae0c6cba3 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3308,18 +3308,22 @@ static int folio_inc_gen(struct lruvec *lruvec, struct folio *folio) > { > int type = folio_is_file_lru(folio); > struct lru_gen_folio *lrugen = &lruvec->lrugen; > - int new_gen, old_gen = lru_gen_from_seq(lrugen->min_seq[type]); > + int new_gen, old_gen, min_gen = lru_gen_from_seq(lrugen->min_seq[type]); > unsigned long new_flags, old_flags = READ_ONCE(*folio_flags(folio, 0)); > > do { > - new_gen = lru_gen_from_flags(old_flags); > + old_gen = lru_gen_from_flags(old_flags); > + /* This helper should never be called for off-list folios */ > + VM_WARN_ON_ONCE(old_gen < 0); > + if (old_gen < 0) > + return min_gen; As Barry doubted, I think this change is wrong. old_gen < 0 in folio_inc_gen() could only happen inc_min_seq() call it. While inc_min_seq() call it because inc_max_seq() need increase max_gen to max_gen + 1 and found get_nr_gens(lruvec, type) == MAX_NR_GENS, it has to move the oldest gen to 2nd old oldest gen. Here returning min_gen for old_gen < 0 means it will be put in the lastest max_gen. It may not be expected. > > /* folio_update_gen() has promoted this page? */ > - if (new_gen >= 0 && new_gen != old_gen) > - return new_gen; > + if (old_gen != min_gen) > + return old_gen; > > new_flags = old_flags; > - new_gen = (old_gen + 1) % MAX_NR_GENS; > + new_gen = (min_gen + 1) % MAX_NR_GENS; > lru_gen_set_flags(&new_flags, new_gen); > lru_refs_set_flags(&new_flags, 0); > } while (!try_cmpxchg(folio_flags(folio, 0), &old_flags, new_flags)); > > -- > 2.55.0 > >