From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) (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 C14773B9D93 for ; Fri, 10 Jul 2026 07:05:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783667152; cv=none; b=BBIDhda/wnoGLz0+/DH2d5CcgHFxKiR5uOWzInP2JzkkxWK2SZxlbATMHZXUHPn/y8IaVD+nW28Q9MWFsm88HDKtiTIyaGajg990Jhpno2oesVhz5tFRb7I/fcclRKU6XXBKuWuIgECI5iDkptOiP2ehi52kAh0zBEnlYu2xatw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783667152; c=relaxed/simple; bh=SMdxQ1e4hRbl/HGd4w8opWxrgBu/ZYoJwQqhe/qyYOU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VBsDof/AsgehyG6r33tAYqzvE74fNnyH1+leG/mBJDDb77B0ZwVr5BifNNCp9aiKThs4ByStXI96PkEM+2xFrqr0IvVFw+ud/AIIFB24NwAbwVc55u0lbgDS1pKiSx6ryK+1EjFNVKZqHyl5npKNmZWw0J2PNeRC9FzOm/VwotA= 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=PfumpgFU; arc=none smtp.client-ip=95.215.58.179 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="PfumpgFU" Message-ID: <9d8627fe-1fb6-47ff-9ca9-ff3b90a12bd8@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1783667147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2IeWWRnXJl0FyJaE8bU1EmfZ2s+EZ/aZ88TxmbZe9QA=; b=PfumpgFUc91Ke3c1jMEhn6jql0L7RatPOOPesyVnqRXUKc1TX6MQ6By9Q1FgPLmxbiGVlQ ttEihD1vbh7LnM1q5LEYFOR1UMmrApPmSiORLB1gWcIJRRZczywx2FIhnf/fyFbgz8g9S6 Snsc6khHrR7KNX8xPXw91Sbz2tINA2k= Date: Fri, 10 Jul 2026 15:05:18 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v5 0/9] mm/page_owner: misc cleanups To: Andrew Morton Cc: Zi Yan , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260701061101.344679-1-ye.liu@linux.dev> <20260701171115.79148d1c7e4f07ebf419c185@linux-foundation.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ye Liu In-Reply-To: <20260701171115.79148d1c7e4f07ebf419c185@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 在 2026/7/2 08:11, Andrew Morton 写道: > On Wed, 1 Jul 2026 14:10:43 +0800 Ye Liu wrote: > >> This series collects a few cleanups for mm/page_owner.c that have been >> accumulated while reading through the file. There is no functional >> change -- the goal is to make the code easier to read and maintain. > > Thanks, updated. > > And... this series is wearing out my keyboard. Please leave it a > week, gather up any additional feedback and only then send v6, if > needed? > Sorry Andrew, I had more time last week and updated more frequently. I will wait and communicate fully for each version. > btw, it's conventional to place the what-changed-since-last-time info > below the ^---$ separator rather than at top-of-changelog. That's where > we place info which isn't appropriate for the mainline tree. > I also have a question about this. Is the changelog placed in [PATCH 0/N] or in the patch [PATCH M/N] that needs to be modified? I've looked at some content on the mailing list, and it seems there are both options. > AI review flagged another possible pre-existing issue. A second > occurrence of the race your "mm/page_owner: fix TOCTOU races in > lockless page state reading" series addresses: > > https://sashiko.dev/#/patchset/20260701061101.344679-1-ye.liu@linux.dev > I will fix this warning in [PATCH 9/9] of V6. >> v5: >> - Place the two patches corresponding to the Close connection, patch8 >> and patch9, together in this part. >> - Close: https://lore.kernel.org/all/20260625014708.87386-1-ye.liu@linux.dev/ >> - Link: https://lore.kernel.org/all/20260701012239.315262-1-ye.liu@linux.dev/ > > Below is how v9 altered mm.git. This is the addition of your > "mm/page_owner: fix TOCTOU races in lockless page state reading" > series, > I've added this part to this patch series. And how to close https://lore.kernel.org/all/20260625014708.87386-1-ye.liu@linux.dev/ ? > > > mm/page_owner.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > --- a/mm/page_owner.c~b > +++ a/mm/page_owner.c > @@ -428,6 +428,12 @@ void __folio_copy_owner(struct folio *ne > * to skip less than the full buddy block, but that is acceptable for page owner > * iteration purposes. > * > + * The lockless read of buddy_order_unsafe() can also return a garbage order if > + * the page is concurrently allocated and PageBuddy is cleared between the check > + * and the read. Clamp the advance at the next MAX_ORDER_NR_PAGES boundary so > + * that a bogus order cannot carry @pfn into an unvalidated memory section, > + * which would break callers that rely on boundary-aligned pfn_valid() checks. > + * > * Return: true if the page was skipped (caller should continue its loop), > * false if the page is not a buddy page and should be processed normally. > */ > @@ -439,8 +445,12 @@ static inline bool skip_buddy_pages(unsi > return false; > > order = buddy_order_unsafe(page); > - if (order <= MAX_PAGE_ORDER) > - *pfn += (1UL << order) - 1; > + if (order <= MAX_PAGE_ORDER) { > + unsigned long new_pfn = *pfn + (1UL << order); > + unsigned long boundary = ALIGN(*pfn + 1, MAX_ORDER_NR_PAGES); > + > + *pfn = min(new_pfn, boundary) - 1; > + } > > return true; > } > @@ -551,7 +561,7 @@ static inline int print_page_owner_memcg > cgroup_name(memcg->css.cgroup, name, sizeof(name)); > ret += scnprintf(kbuf + ret, count - ret, > "Charged %sto %smemcg %s\n", > - PageMemcgKmem(page) ? "(via objcg) " : "", > + (memcg_data & MEMCG_DATA_KMEM) ? "(via objcg) " : "", > online ? "" : "offline ", > name); > out_unlock: > _ > -- Thanks, Ye Liu