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=1792583353; b=aDbpjTrnqeVhXhkrYKcvQwS8PySU9eNrPoH5Kss3ZJuKr09QjvyySTrwx7jGbGTjxi2Q TtndZMMgnbNO3gp8rEQcWBQ55N5awt6sSFNR+vat51/S4urXqLKldt7djoH1ScnA5h/Ja y1cyG1AdeX38360K5GnkzV/E5ChHIUsgtfh10dMt/0JlDToTqvRMxure8n2IGTsSjE1/2 LCDLYJO3glyve/pNlJ8knitwSlKslf5fSDVpynsIsA6jL1DpUEQT7rTPWxvbta2rmdQ4O wRLXzz+MxHbVMToijxQnyFqwDGatMPTePSQol3zBcjy89fM8/3FbERLMbu8M0NxXGMA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792583353; h=Received:DKIM-Signature:Message-ID:From:Subject:Reply-To:To:Cc: In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=FjU3V+rd8zjjpGJql233pQuD6ax8MAtzDfiydIJHxGw=; b=o2fXDpGQ4+jY3821zu4wMogfG07cSUPeEPmuJ90fbisOHfsUwUKCwTAy6JGmOxn3fqGW O+Qu0ZMxjlTGa73X1HYIXUW3O1TP7K/62ZrlZunXc396lWpkddBn/bDJi8fjWfpmhTxYb QXWB38ijM/Hb0Vo9YBCNEAb6YxVzTBwW0R7/SQCXWK36udcENyU+WzBixyhWyCMiKLME1 nf4t11ZD7vwTvVZ3BNSCwcggpUauYBx0J4ByZ0IDzotYG9E2uOyUQ6gjbAyYWscOX5Dz0 UPDPwCz++zVbiMjZ5408c/U+fc7nnJ1ohG8K8fX4k1aLGn1cfFDzGZQkLrXSsSOGlYg== 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="Zj/Rld9E"; 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 B7E63606A32A for ; Wed, 21 Oct 2026 11:49:12 +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=Zj/Rld9E Received: by smtp.kernel.org (Postfix) with ESMTPSA id 658EA1F000C7; Wed, 21 Oct 2026 11:49:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792583352; bh=FjU3V+rd8zjjpGJql233pQuD6ax8MAtzDfiydIJHxGw=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Zj/Rld9EDCqOTfy6Op98uGK996/oHg6AFPiUzQHvATS2lJJxkpBk0JAzqY8edadT6 Sck6dbYuRaJ6se2+9dfM/UEuk22X1W/oCRcT0BUJVOujn2oWDJ9ENER/1eJgCM3aPF YxOSkF4Otq9wd6oXioXyJcPdgESuHiyLQy47dU/oxYHZ1J1EdjHj7/nc2r7yDwUR4G LKqI/+jGgoM9tfVLEHFHxEcKkKogF+K/F8yaVntTaSTzsLTwuuJwesqSA+/ey2R/bT xFzqvFIyigsd611/OjtZCpduUe1GFASmJGTmvBcqzAdpLnuUkDI40upmy0ppGV9M/p W4Elgji0ic5jA== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 6/7] mm/page_owner: add bpf_page_owner_get_memcg_info() kfunc Reply-To: sashiko-reviews@lists.linux.dev To: "Zhen Ni" , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, eddyz87@gmail.com, memxor@gmail.com, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org, emil@etsalapatis.com, ihor.solodrai@linux.dev, akpm@linux-foundation.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, brendan.jackman@linux.dev, hannes@cmpxchg.org, ziy@nvidia.com, shuah@kernel.org Cc: bpf@vger.kernel.org, linux-mm@kvack.org In-Reply-To: <20261021112437.1799213-7-zhen.ni@easystack.cn> References: <20261021112437.1799213-1-zhen.ni@easystack.cn> <20261021112437.1799213-7-zhen.ni@easystack.cn> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2026 11:49:10 +0000 X-Mailing-List: bpf@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 3 potential issue(= s) to consider: - [High] mm/page_owner: tail page _nr_pages dereferenced as objcg in get_pa= ge_memcg_info() - [Medium] mm/page_owner: __uninit in bpf_page_owner_get_memcg_info() poiso= ns stack - [Medium] mm/page_owner: missing __nullable on buf in bpf_page_owner_get_m= emcg_info() -- commit 6c73498afe7c643ebd28b236a8d852daad168a14 Author: Zhen Ni mm/page_owner: add bpf_page_owner_get_memcg_info() kfunc This commit factors per-page memcg lookup out of print_page_owner_memcg() into get_page_memcg_info() and adds the bpf_page_owner_get_memcg_info() kfunc so BPF page_owner iterators can retrieve memcg metadata and the full cgroup path. [ ... ] > diff --git a/mm/page_owner.c b/mm/page_owner.c > index 8bc15bcdc24e9..7470b5d002be4 100644 > --- a/mm/page_owner.c > +++ b/mm/page_owner.c > @@ -538,16 +538,22 @@ void pagetypeinfo_showmixedcount_print(struct seq_f= ile *m, > =20 > #ifdef CONFIG_MEMCG > /* > - * Looking for memcg information and print it out > + * Collect memcg information of @page into @info; when @buf and a > + * nonzero @size are given, also copy the full cgroup path of the > + * charged memcg into @buf. > + * > + * Return: 0 if @page is charged to an attributable memcg; -ENODATA > + * otherwise. > */ > -static inline int print_page_owner_memcg(char *kbuf, size_t count, int r= et, > - struct page *page) > +int get_page_memcg_info(struct page *page, struct memcg_info *info, > + char *buf, int size) > { > unsigned long memcg_data; > struct obj_cgroup *objcg; > struct mem_cgroup *memcg; > - bool online; > - char name[80]; > + int ret =3D -ENODATA; > + > + *info =3D (struct memcg_info){}; > =20 > rcu_read_lock(); > memcg_data =3D READ_ONCE(page->memcg_data); > @@ -555,31 +561,68 @@ static inline int print_page_owner_memcg(char *kbuf= , size_t count, int ret, > goto out_unlock; > =20 > if (memcg_data & MEMCG_DATA_OBJEXTS) { > - ret +=3D scnprintf(kbuf + ret, count - ret, > - "Slab cache page\n"); > + info->is_slab =3D true; > goto out_unlock; > } > =20 > objcg =3D (void *)(memcg_data & ~OBJEXTS_FLAGS_MASK); > - memcg =3D objcg ? obj_cgroup_memcg(objcg) : NULL; > + if (!objcg) > + goto out_unlock; > + > + memcg =3D obj_cgroup_memcg(objcg); [Severity: High] Can get_page_memcg_info() in mm/page_owner.c dereference folio->_nr_pages as a struct obj_cgroup pointer when inspecting tail page 1 of a compound folio? In struct folio (include/linux/mm_types.h), the first tail page (__page_1) places _nr_pages at the same offset as struct page::memcg_data: include/linux/mm_types.h:struct folio { ... atomic_t _mapcount_1; atomic_t _refcount_1; #ifdef NR_PAGES_IN_LARGE_FOLIO unsigned int _nr_pages; #endif }; struct page __page_1; ... } For a compound folio with order >=3D 3, _nr_pages is 1U << order (for examp= le, 0x8 or 0x200), so its low bits matching OBJEXTS_FLAGS_MASK are zero. Because bpf_page_owner_get_memcg_info() in mm/page_owner_iter.c calls get_page_memcg_info() on scan->pfn without stabilizing the page reference or folio state (and struct page_owner_scan is a scalar-only struct that a BPF program can also populate on the stack or in a map), page can refer to tail page 1 of a compound folio. In get_page_memcg_info(), page->memcg_data is read before checking PageTail(page): memcg_data =3D READ_ONCE(page->memcg_data); if (!memcg_data || PageTail(page)) goto out_unlock; If tail page 1 is concurrently freed via __free_pages_prepare() -> free_tail_page_prepare() -> clear_compound_head() after READ_ONCE() reads _nr_pages into memcg_data, or if the folio is concurrently split to order 0 in mm/huge_memory.c:__split_folio_to_order() where clear_compound_head() clears PageTail(new_head) before new_folio->memcg_data overwrites _nr_pages: mm/huge_memory.c:__split_folio_to_order() { ... clear_compound_head(new_head); if (new_order) { prep_compound_page(new_head, new_order); folio_set_large_rmappable(new_folio); } ... #ifdef CONFIG_MEMCG new_folio->memcg_data =3D folio->memcg_data; #endif } wouldn't PageTail(page) evaluate to false while memcg_data holds 1UL << ord= er, causing obj_cgroup_memcg(objcg) to dereference that page count as a pointer? [ ... ] > diff --git a/mm/page_owner_iter.c b/mm/page_owner_iter.c > index b7e0ce1dfa80a..a649e1207e246 100644 > --- a/mm/page_owner_iter.c > +++ b/mm/page_owner_iter.c > @@ -181,4 +181,52 @@ __bpf_kfunc int bpf_page_owner_stack_snprint(struct = page_owner_scan *scan, > return len; > } > =20 > +/** > + * bpf_page_owner_get_memcg_info - Report the memcg charged for the curr= ent page > + * @scan: page_owner scan handle. > + * @info__uninit: output buffer for the memcg_info. > + * @buf__uninit: optional output buffer for the full cgroup path. > + * @buf__sz: size of @buf__uninit. > + * > + * Fills @info__uninit with the memcg charged for the page backing > + * @scan->pfn. If @buf__uninit and @buf__sz are provided, the full > + * cgroup path is also copied out, so a BPF program can attribute a > + * page_owner allocation to a specific cgroup. > + * > + * @scan->pfn is resolved to a struct page under get_online_mems(), > + * so the page cannot be accessed after its memory section is offlined > + * or removed. > + * > + * Returns: > + * * 0 on success > + * * -ENODATA if the page is not online or not charged to a memcg > + * * -EOPNOTSUPP if built without CONFIG_MEMCG > + */ > +__bpf_kfunc int bpf_page_owner_get_memcg_info(struct page_owner_scan *sc= an, > + struct memcg_info *info__uninit, > + char *buf__uninit, u32 buf__sz) [Severity: Medium] Will the __uninit suffix on info__uninit and buf__uninit in bpf_page_owner_get_memcg_info() (mm/page_owner_iter.c) cause the BPF verifi= er to reject valid programs that pass stack buffers across a pruning checkpoin= t? In kernel/bpf/verifier.c:bpf_kfunc_stack_access_bytes(), any kfunc argument matching is_kfunc_arg_uninit() returns a negative size: if (is_kfunc_arg_uninit(btf, &args[arg])) return -size; return size; That negative size tells record_stack_access_off() in kernel/bpf/liveness.c that the kfunc call overwrites the stack slots without reading them, so sta= tic stack liveness analysis marks those slots dead prior to the call. When clean_verifier_state() -> __clean_func_state() in kernel/bpf/states.c runs = at an earlier pruning checkpoint (such as the second iteration of bpf_iter_page_owner_next(), or a branch/call after stack allocation), it poisons those dead stack slots with STACK_POISON: for (j =3D start; j < end; j++) st->stack[i].slot_type[j] =3D STACK_POISON; However, check_kfunc_args() in kernel/bpf/verifier.c only honors is_kfunc_arg_uninit() for KF_ARG_PTR_TO_DYNPTR. For KF_ARG_PTR_TO_MEM (info__uninit) and KF_ARG_MEM_SIZE (buf__uninit), check_kfunc_args() valida= tes the buffers with BPF_READ | BPF_WRITE: ret =3D check_mem_reg(env, reg, argno, type_size, BPF_READ | BPF_WRITE, meta, &known_memory); ... ret =3D check_mem_size_reg(env, buff_reg, size_reg, buff_argno, argno, BPF_READ | BPF_WRITE, true, meta, &failure); When check_stack_range_initialized() in kernel/bpf/verifier.c performs the BPF_READ check with allow_poison =3D=3D false, it hits *stype =3D=3D STACK_= POISON and fails verification with -EACCES ("slot poisoned by dead code elimination"). > +{ > + struct page *page; > + int ret =3D -ENODATA; > + > + if (!static_branch_unlikely(&page_owner_inited)) > + goto nodata; > + > + get_online_mems(); > + page =3D pfn_to_online_page(scan->pfn); > + if (!page) { > + put_online_mems(); > + goto nodata; > + } > + ret =3D get_page_memcg_info(page, info__uninit, buf__uninit, buf__sz); > + put_online_mems(); > + return ret; > + > +nodata: > + *info__uninit =3D (struct memcg_info){}; > + if (buf__uninit && buf__sz) > + buf__uninit[0] =3D '\0'; [Severity: Medium] Should the optional cgroup path buffer parameter in bpf_page_owner_get_memcg_info() (mm/page_owner_iter.c) use a __nullable suffix so BPF programs can pass NULL when they only need struct memcg_info? Both bpf_page_owner_get_memcg_info() and get_page_memcg_info() check whether buf is NULL, and the kernel-doc describes buf__uninit as an optional output buffer. However, in kernel/bpf/verifier.c:get_kfunc_arg_type(), PTR_MAYBE_N= ULL is only added when is_kfunc_arg_nullable() matches the "__nullable" (or "__arena") suffix: static bool is_kfunc_arg_nullable(const struct btf *btf, const struct btf_p= aram *arg) { return btf_param_match_suffix(btf, arg, "__nullable") || btf_param_match_suffix(btf, arg, "__arena"); } Without a __nullable suffix on the buffer argument, check_kfunc_args() in kernel/bpf/verifier.c rejects a BPF program that passes NULL (or a PTR_MAYBE_NULL register) for arg#3 with -EACCES ("Possibly NULL pointer pas= sed to trusted arg#3"). > + return ret; > +} > + > __bpf_kfunc_end_defs(); --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261021112437.1799= 213-1-zhen.ni@easystack.cn?part=3D6