linux-kernel - Re: [BUG] WARNING in __alloc_frozen_pages

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: <4cb9f727-734b-43fa-92d2-80559df76c84@suse.cz>
Date: Wed, 26 Nov 2025 10:46:38 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Xianying Wang <wangxianying546@...il.com>, akpm@...ux-foundation.org
Cc: surenb@...gle.com, mhocko@...e.com, jackmanb@...gle.com,
 hannes@...xchg.org, ziy@...dia.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
 Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>,
 Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
 Adrian Hunter <adrian.hunter@...el.com>,
 "Liang, Kan" <kan.liang@...ux.intel.com>, linux-perf-users@...r.kernel.org
Subject: Re: [BUG] WARNING in __alloc_frozen_pages_noprof

+CC perf people as AFAIU the problem originates there. Should the limit
be lowered, or the allocations e.g. switched to kvmalloc, to avoid
requesting impossibly high order allocations?

        /*
         * There are several places where we assume that the order value is sane
         * so bail out early if the request is out of bound.
         */
        if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp))
                return NULL;



On 11/19/25 10:07 AM, Xianying Wang wrote:
> Hi,
> 
> I hit the following warning in the page allocator when opening a perf
> event with callchain sampling after increasing
> kernel.perf_event_max_stack.This warning can be triggered by first
> writing a large value into kernel.perf_event_max_stack and then
> opening a perf event with callchain sampling enabled.
> 
> The reproducer does two things:
> 
> 1) It writes a large (but still accepted) value to the sysctl:
> 
> echo 0x40132 > /proc/sys/kernel/perf_event_max_stack
> 
> (0x40132 = 262450 in decimal. This is below the current upper bound
> 
> enforced by perf_event_max_stack_handler(), which uses 640 * 1024
> 
> as extra2.)
> 
> 2) It calls perf_event_open() with callchain sampling:
> 
> struct perf_event_attr attr = {
> 
> .type = PERF_TYPE_HARDWARE,
> 
> .size = sizeof(attr),
> 
> .config = PERF_COUNT_HW_CPU_CYCLES,
> 
> .sample_type = PERF_SAMPLE_CALLCHAIN,
> 
> .sample_period = 1,
> 
> .disabled = 1,
> 
> };
> 
> fd = syscall(__NR_perf_event_open, &attr, -1, 0, -1, 0);
> 
> The same warning is reproducible on both v6.17.0 and v6.18-rc2
> (6.18.0-rc2-00120 g6fab32bb6508), only the line numbers in
> __alloc_frozen_pages_noprof() differ slightly.
> 
> The suspected cause is that alloc_callchain_buffers() uses
> sysctl_perf_event_max_stack directly when computing the size of the
> per-CPU callchain buffers. For large but valid values of
> kernel.perf_event_max_stack, perf_callchain_entry__sizeof() grows to
> several megabytes, and alloc_callchain_buffers() ends up doing a very
> large contiguous kmalloc_node() per CPU. This high-order allocation
> then triggers the warning in __alloc_frozen_pages_noprof() in the page
> allocator.
> 
> This can be reproduced on:
> 
> HEAD commit:
> 
> e5f0a698b34ed76002dc5cff3804a61c80233a7a
> 
> 6fab32bb6508abbb8b7b1c5498e44f0c32320ed5
> 
> report: https://pastebin.com/raw/bCq3d4KR
> 
> console output : https://pastebin.com/raw/5hfk57Vd
> 
> kernel config : https://pastebin.com/raw/1grwrT16
> 
> C reproducer :https://pastebin.com/raw/GADWbwKN
> 
> Let me know if you need more details or testing.
> 
> Best regards,
> 
> Xianying