[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aSdORdgxGSOERQZr@google.com>
Date: Wed, 26 Nov 2025 11:00:21 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Vlastimil Babka <vbabka@...e.cz>,
Xianying Wang <wangxianying546@...il.com>,
akpm@...ux-foundation.org, surenb@...gle.com, mhocko@...e.com,
jackmanb@...gle.com, hannes@...xchg.org, ziy@...dia.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...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
Hello,
On Wed, Nov 26, 2025 at 12:19:21PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 26, 2025 at 10:46:38AM +0100, Vlastimil Babka wrote:
> > +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
> > >
>
> Yeah, that is far too large. I suppose the actual max is somewhere near
> 8k, which would give 64k data for just the callchain -- given that a
> single perf buffer entry is limited to 64k (IIRC) and all that.
Right, we have u16 size in struct perf_event_header.
Thanks,
Namhyung
Powered by blists - more mailing lists