From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793161354; b=nSuWLrFjGZ/tRQVqMrnITBgajZeMP5f0PkhcUSVUEjKReJPG9Xjf2xJeUGkdDdJwQ0zp lNrmoXiMBLai8WRHvCCV8Xg2d7riihl1SBOprwoWUMH57Ycpr2QDqJC97OgfWURnlyyn+ ksxEy/adI08eusRcY+pmLkIBn+51iNF5ldnihb7AKok35bNCICXmWkoieeVHBwBouahV3 f9R2cAeZFheKPSKwEQWhI0Z9MeNTUEOY7sPlrlked0EulfbYj0QjAL8kq/SpOxjua6W52 e5UMubwwbUCKrruxRpH7qjw9hvi1JOvjE/wFoaSdMTQvU+DIjgkqqn1QqiwwjnVL11g== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793161354; h=Received:DKIM-Signature:Message-ID:From:Subject:Reply-To:To:Cc: In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=vkyQ8vHhkWSt512yuI1HFfvtHuYn2OinQNhM77ow/sg=; b=SPLF0csIp8V2mx4+zkhopZWqvMNktmKw9fGb2gSGxeNSMv4i1LW+DlH9ykyFMQ3y2/Jr kgWkvK4btk0DfVqnmK77PeOgLpiOpJWFpuw8/KpBh1fLY3koSREQ5kdlVgOBymMSkQlcz K8ccQdMSJ3IRXU2rJYne5aHBObVgDQrkHv/cXvSHsoC3UiaD9i4Kzg+2j3gRkRNNqRpmy A5WD3Oya1arKDpvxlDTMTrMOPZaHJgog0e1UfK1dpskJ1N62dpjfNwKl4JB3VrC5xQqF4 59qlPppM7SLHIy0VV+4u0eJ9S7OZSptmN7TvdbFHCbwgjKTQzUv4LCI0psjZRTIDB9w== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=U0I9hRGg; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F3F38606A31A for ; Wed, 28 Oct 2026 04:22:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=U0I9hRGg Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE6141F01825; Wed, 28 Oct 2026 04:22:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793161353; bh=vkyQ8vHhkWSt512yuI1HFfvtHuYn2OinQNhM77ow/sg=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=U0I9hRGgBbIvYWK4Y3maDxqSJe8UWuC/jqU3jpE5KHNCyZpc2lTw8E/yB7HZHpgn4 ulM6xIxcCByD/EAXHJWGfpoKRsXaiuC+aravlHhYAgtH3EinlFI9sBdCF4fYEG4tPM Z7E+QVHqiwP6fSSJUM/MmPjThC8gGnu8q3XG02RWhyH86TodyLhfkx3mD1sZXgB8nb wsnAi9CpfKxXBholTq4YtSx8j8scXxIpf/WdB100K1/c8QpZbM1caJNS/wQGwPh8I7 WyAD3e0703tdgK4zSHBFf3RHA4QxMZeZtY5sBjlbq1aIDE+05s/gZF/aTczBoCzfug zsvlYFHsuxycQ== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH 2/6] mm/page_owner: hold off memory offline while a page is read Reply-To: sashiko-reviews@lists.linux.dev To: =?utf-8?b?R3JlZ29yeSBQcmljZSAoTWV0YSk=?= , linux-mm@kvack.org Cc: linux-cxl@vger.kernel.org, kernel-team@meta.com, akpm@linux-foundation.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, brendan.jackman@linux.dev, hannes@cmpxchg.org, ziy@nvidia.com, linmiaohe@huawei.com, nao.horiguchi@gmail.com, david@kernel.org, ljs@kernel.org, liam@infradead.org, rppt@kernel.org, osalvador@suse.de, muchun.song@linux.dev, iamjoonsoo.kim@lge.com, anshuman.khandual@arm.com In-Reply-To: <20261027042204.3741307-3-gourry@gourry.net> References: <20261027042204.3741307-1-gourry@gourry.net> <20261027042204.3741307-3-gourry@gourry.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2026 04:22:32 +0000 X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [Medium] mm/page_owner: read_page_owner() mixes guard(pfn_walk) with goto= cleanup -- commit b2d3acd01e2d83565fff990fcda39fb4ee08ffa7 Author: Gregory Price (Meta) mm/page_owner: hold off memory offline while a page is read This commit prevents page faults during concurrent memory offlining or remo= val when reading /sys/kernel/debug/page_owner by checking PFNs with pfn_to_online_page() inside a pfn_walk read section and moving kmalloc() and copy_to_user() outside that section. > diff --git a/mm/page_owner.c b/mm/page_owner.c > index cfc31c92d7657..d2c0b831fcd3b 100644 > --- a/mm/page_owner.c > +++ b/mm/page_owner.c [ ... ] > @@ -766,7 +760,12 @@ read_page_owner(struct file *file, char __user *buf,= size_t count, loff_t *ppos) > continue; > } > =20 > - page =3D pfn_to_page(pfn); > + /* Offline waits for us before it poisons the memmap */ > + guard(pfn_walk)(); > + page =3D pfn_to_online_page(pfn); > + if (!page) > + continue; > + > if (skip_buddy_pages(&pfn, page)) > continue; > =20 > @@ -825,14 +824,18 @@ read_page_owner(struct file *file, char __user *buf= , size_t count, loff_t *ppos) > =20 > page_owner_tmp =3D *page_owner; > page_ext_put(page_ext); > - return print_page_owner(buf, count, pfn, page, > + ret =3D print_page_owner(kbuf, count, pfn, page, > &page_owner_tmp, handle, state); > + break; > ext_put_continue: > page_ext_put(page_ext); > cond_resched(); > } [Severity: Medium] In read_page_owner(), guard(pfn_walk)() is declared inside the for-loop bod= y, so its scope extends to the closing brace of the loop after cond_resched(). When a PFN is skipped via goto ext_put_continue (for example on an unalloca= ted page, tail page, missing handle, or filtered node ID): mm/page_owner.c:read_page_owner() { for (; pfn < max_pfn; pfn++) { ... guard(pfn_walk)(); ... if (!test_bit(PAGE_EXT_OWNER, &page_ext->flags)) goto ext_put_continue; ... ext_put_continue: page_ext_put(page_ext); cond_resched(); } } First, include/linux/cleanup.h notes that goto-based cleanup and scope-based cleanup helpers should not be mixed in the same function. Second, because the guard(pfn_walk) scope only ends at the closing brace of the loop, cond_resched() is called while the pfn_walk SRCU read lock is sti= ll held, even though all accesses to struct page and page_ext for that PFN have already completed. If the task is scheduled out in cond_resched(), concurre= nt memory offlining in offline_pages() -> remove_pfn_range_from_zone() -> pfn_walk_synchronize() has to wait for the reader to be scheduled back in while holding the memory hotplug locks. Should the pfn_walk guard and page_ext cleanup be scoped so that the pfn_wa= lk read section ends before cond_resched(), and without mixing guard() with goto-based cleanup? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261027042204.3741= 307-1-gourry@gourry.net?part=3D2