From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 1BB3C2EAD16 for ; Thu, 18 Dec 2025 14:26:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766067983; cv=none; b=D2KKmRpKuHpbgygTTtdQZM/Xb/SFMNLEU5/C3RuAFnWv4KCFfx4Qp22YuTDBIqlJGi0LQty4LNAApQdMPWm7jYYJpspWtcwbDQ5Ayk8/FtnZBHcxINrcTi8E/lgiKouVEwUk+i8H7Lxsh5Mw55oXZOzKntn6Ym01zaaSukfxY7Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766067983; c=relaxed/simple; bh=+tqbzSsCOlNx3bYnQg0e6G2u96ugel+0x7WAXg56Ir8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nosi3T6fa87tYS6sKh4uRtUhXIN0FPkbQpEnRF+350gq2w9nXm1UDL2R5NpUkb/az6iWnp7n3+6XcVDI+NDSBm+Ur2Pzi/LZhZoNMaTXPmKVrvFzsgfuyaFXvg/hPg/5+iVMCbIP1AHr8yWnUdWlPAGlFmyhBTpKipAILDoS2tY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=bXJDC5QQ; arc=none smtp.client-ip=209.85.222.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="bXJDC5QQ" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-8b2d6df99c5so174614185a.1 for ; Thu, 18 Dec 2025 06:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1766067979; x=1766672779; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=O4JfDdWMGPq8CSrxduIu7FfagUjVyoTiMCySGeC3YnI=; b=bXJDC5QQ+cYAW4r6KI0wTzVHVJRtlYPAMDK493B7+Qq63cHV/zFVDJPhILlaR5anoR HIZF9duOMGIXI3usiTOU+EjvodPjr/5SKhnIQrsMn33qFi3QuwwQ8HpqXeISZxZBeaQm MYyN64Li762lXYqDG0CZGi696pauDqwvjs9R5OywtzurzLz9x7jbQZbO9LsHl9MatB55 ewXGqaSgG2qrR6hTNQl/8wEXZSEjL/2vs+YCHtAW7bg4u+r/hBlczK6vJKPd2n1mCv5j y0MXrEvQTvUdc+GROdPKojofJUnGz/DH38Oeoycn/VyKW5F38unZe4srtXj4zlcgsFBb A6jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766067979; x=1766672779; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O4JfDdWMGPq8CSrxduIu7FfagUjVyoTiMCySGeC3YnI=; b=jlP7L9YHCi61D9ERi4KKF3aa3xbFCPn2yAboWs1m5yGaPyQhRqXCFk4GWxFWh4P7gi 6if4hNusIM8vgnJZlAcySQXuBj1itrEMdKTDpmKBHBkz4wTsyeIqFBt/pJoIJAhqHNKt Dl1M1+eAA97sdklkzkzi09IdjiXcTbT510K9IbGcpSsTsGpbO4D73BY5hcTyy2bCE8Gr QOnI9qiqdJGrB0zq3biDtRteNczJQma1VaE/ppmc9ca/l1pZCSET47Hx4rMzYfTAUz1q 9KEo9kL508TMXAQ1SdtkDprQ9nSqZheEVAjAvv/viuSl7XuPFX13xSXB3zhNujd93DsA YiEg== X-Forwarded-Encrypted: i=1; AJvYcCXIvBQuYwc42BIK4Csa80YpUXGm8AubhIM8kaWPXzNtccTcYZMUu2ituHrSJJSbzmjM+pwE67vTg9Ey+1Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzjgB2dusLvKOrN/cS4je0/sg2BXG8oDcYBRR7nsGoTWBY+V7Ia uHVMvLQWy2DSxLAVMWb1c0gaCIodExzkkoLXRNLq1mEPKEdgNdSM+QuIpP965vXKSdU= X-Gm-Gg: AY/fxX4/2VlFmaqgIHPeDXGy00PqxM9HM/J8akYD3LSMjneZbRuCvhunx2kH1T4AUi6 FfanimES0gISRa1mr3WObHfjllv8Blz8n65s/sGj3csgQI7gZYZhO2DYcCy+VgERnYcnqHd7lzP 1jMEpqiXOdITX112Rlh7wNOUo8zW+REwLbZEUEZHuW5GfLJkaDeSfIEnPuF7TIO4Y/g1S5C3E6T z9mrA2W5NcynPxYvwJ1S3tSCFAsmbEPUqZlbkVa5qJiysqmk8aa4zqjwBi13mrNZCKS5fPiGbaC gnYUA1WADuvKqfq3c4m6b9ahAZuLnyMqnoEQAqILysDo+nWKRjfBgA6Y4nNoeRvLXwX7gsNNZdT KU4D40lqB4ZA/Wy/D0u9oR1VA8k6nWfkyDHlFLmnUCqZTIEAt0E66f772NF/ygXjamRsglYdbK5 HsXAs0YwtnRw== X-Google-Smtp-Source: AGHT+IELq2RKx20U60QDHWt5nbgZD6b0sDzQmfp1LT1fm0LfAa5ovOYvirAd5MjdzrOUr19AMKNjZA== X-Received: by 2002:a05:6214:2d46:b0:880:5589:54cd with SMTP id 6a1803df08f44-88c51e5859dmr46310956d6.19.1766067979375; Thu, 18 Dec 2025 06:26:19 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88c6089a7c3sm18147036d6.27.2025.12.18.06.26.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Dec 2025 06:26:18 -0800 (PST) Date: Thu, 18 Dec 2025 09:26:15 -0500 From: Johannes Weiner To: "David Hildenbrand (Red Hat)" Cc: Qi Zheng , hughd@google.com, mhocko@suse.com, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, lorenzo.stoakes@oracle.com, ziy@nvidia.com, harry.yoo@oracle.com, imran.f.khan@oracle.com, kamalesh.babulal@oracle.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, chenridong@huaweicloud.com, mkoutny@suse.com, akpm@linux-foundation.org, hamzamahfooz@linux.microsoft.com, apais@linux.microsoft.com, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Muchun Song , Qi Zheng Subject: Re: [PATCH v2 13/28] mm: migrate: prevent memory cgroup release in folio_migrate_mapping() Message-ID: References: <1554459c705a46324b83799ede617b670b9e22fb.1765956025.git.zhengqi.arch@bytedance.com> <3a6ab69e-a2cc-4c61-9de1-9b0958c72dda@kernel.org> 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: <3a6ab69e-a2cc-4c61-9de1-9b0958c72dda@kernel.org> On Thu, Dec 18, 2025 at 10:09:21AM +0100, David Hildenbrand (Red Hat) wrote: > On 12/17/25 08:27, Qi Zheng wrote: > > From: Muchun Song > > > > In the near future, a folio will no longer pin its corresponding > > memory cgroup. To ensure safety, it will only be appropriate to > > hold the rcu read lock or acquire a reference to the memory cgroup > > returned by folio_memcg(), thereby preventing it from being released. > > > > In the current patch, the rcu read lock is employed to safeguard > > against the release of the memory cgroup in folio_migrate_mapping(). > > We usually avoid talking about "patches". > > In __folio_migrate_mapping(), the rcu read lock ... > > > > > This serves as a preparatory measure for the reparenting of the > > LRU pages. > > > > Signed-off-by: Muchun Song > > Signed-off-by: Qi Zheng > > Reviewed-by: Harry Yoo > > --- > > mm/migrate.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/migrate.c b/mm/migrate.c > > index 5169f9717f606..8bcd588c083ca 100644 > > --- a/mm/migrate.c > > +++ b/mm/migrate.c > > @@ -671,6 +671,7 @@ static int __folio_migrate_mapping(struct address_space *mapping, > > struct lruvec *old_lruvec, *new_lruvec; > > struct mem_cgroup *memcg; > > > > + rcu_read_lock(); > > memcg = folio_memcg(folio); > > In general, LGTM > > I wonder, though, whether we should embed that in the ABI. > > Like "lock RCU and get the memcg" in one operation, to the "return memcg > and unock rcu" in another operation. > > Something like "start / end" semantics. The advantage of open-coding this particular one is that 1) rcu_read_lock() is something the caller could already be holding/using, implicitly or explicitly; and 2) it's immediately obvious that this is an atomic section (which was already useful in spotting a bug in the workingset patch of this series). "start/end" terminology hides this. "lock" we can't use because it would suggest binding stability. The only other idea I'd have would be to spell it all out: memcg = folio_memcg_rcu_read_lock(folio); stuff(memcg); otherstuff(); rcu_read_unlock(); But that might not be worth it. Maybe somebody can think of a better name. But I'd be hesitant to trade off the obviousness of what's going on given how simple the locking + access scheme is.