linux-kernel - Re: [RFC mm v6] mm: introduce a new page type for page pool in page type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f25a95a4-5371-40bd-8cc8-d5f7ede9a6ac@kernel.org>
Date: Mon, 17 Nov 2025 17:02:24 +0100
From: Jesper Dangaard Brouer <hawk@...nel.org>
To: Byungchul Park <byungchul@...com>, linux-mm@...ck.org,
 netdev@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, kernel_team@...ynix.com,
 harry.yoo@...cle.com, ast@...nel.org, daniel@...earbox.net,
 davem@...emloft.net, kuba@...nel.org, john.fastabend@...il.com,
 sdf@...ichev.me, saeedm@...dia.com, leon@...nel.org, tariqt@...dia.com,
 mbloch@...dia.com, andrew+netdev@...n.ch, edumazet@...gle.com,
 pabeni@...hat.com, akpm@...ux-foundation.org, david@...hat.com,
 lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
 rppt@...nel.org, surenb@...gle.com, mhocko@...e.com, horms@...nel.org,
 jackmanb@...gle.com, hannes@...xchg.org, ziy@...dia.com,
 ilias.apalodimas@...aro.org, willy@...radead.org, brauner@...nel.org,
 kas@...nel.org, yuzhao@...gle.com, usamaarif642@...il.com,
 baolin.wang@...ux.alibaba.com, almasrymina@...gle.com, toke@...hat.com,
 asml.silence@...il.com, bpf@...r.kernel.org, linux-rdma@...r.kernel.org,
 sfr@...b.auug.org.au, dw@...idwei.uk, ap420073@...il.com, dtatulea@...dia.com
Subject: Re: [RFC mm v6] mm: introduce a new page type for page pool in page
 type


On 17/11/2025 06.20, Byungchul Park wrote:
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 600d9e981c23..01dd14123065 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1041,7 +1041,6 @@ static inline bool page_expected_state(struct page *page,
>   #ifdef CONFIG_MEMCG
>   			page->memcg_data |
>   #endif
> -			page_pool_page_is_pp(page) |
>   			(page->flags.f & check_flags)))
>   		return false;
>   
> @@ -1068,8 +1067,6 @@ static const char *page_bad_reason(struct page *page, unsigned long flags)
>   	if (unlikely(page->memcg_data))
>   		bad_reason = "page still charged to cgroup";
>   #endif
> -	if (unlikely(page_pool_page_is_pp(page)))
> -		bad_reason = "page_pool leak";
>   	return bad_reason;
>   }

This code have helped us catch leaks in the past.
When this happens the result is that the page is marked as a bad page.

>   
> @@ -1378,9 +1375,12 @@ __always_inline bool free_pages_prepare(struct page *page,
>   		mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1);
>   		folio->mapping = NULL;
>   	}
> -	if (unlikely(page_has_type(page)))
> +	if (unlikely(page_has_type(page))) {
> +		/* networking expects to clear its page type before releasing */
> +		WARN_ON_ONCE(PageNetpp(page));
>   		/* Reset the page_type (which overlays _mapcount) */
>   		page->page_type = UINT_MAX;
> +	}
>   
>   	if (is_check_pages_enabled()) {
>   		if (free_page_is_bad(page))

What happens to the page? ... when it gets marked with:
   page->page_type = UINT_MAX

Will it get freed and allowed to be used by others?
- if so it can result in other hard-to-catch bugs

--Jesper