[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV0qxGioAXxkh6QD@J2N7QTR9R3>
Date: Tue, 6 Jan 2026 15:31:16 +0000
From: Mark Rutland <mark.rutland@....com>
To: Breno Leitao <leitao@...ian.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Laura Abbott <labbott@...hat.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>, kernel-team@...a.com,
puranjay@...nel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] arm64: Disable branch profiling for all arm64 code
On Tue, Jan 06, 2026 at 06:05:37AM -0800, Breno Leitao wrote:
> On Tue, Jan 06, 2026 at 12:21:47PM +0000, Mark Rutland wrote:
> > On Tue, Jan 06, 2026 at 02:16:35AM -0800, Breno Leitao wrote:
> > > The arm64 kernel doesn't boot with annotated branches
> > > (PROFILE_ANNOTATED_BRANCHES) enabled and CONFIG_DEBUG_VIRTUAL together.
> > >
> > > Bisecting it, I found that disabling branch profiling in arch/arm64/mm
> > > solved the problem. Narrowing down a bit further, I found that
> > > physaddr.c is the file that needs to have branch profiling disabled to
> > > get the machine to boot.
> > >
> > > I suspect that it might invoke some ftrace helper very early in the boot
> > > process and ftrace is still not enabled(!?).
> > >
> > > Rather than playing whack-a-mole with individual files, disable branch
> > > profiling for the entire arch/arm64 tree, similar to what x86 already
> > > does in arch/x86/Kbuild.
> > >
> > > Cc: stable@...r.kernel.org
> > > Fixes: ec6d06efb0bac ("arm64: Add support for CONFIG_DEBUG_VIRTUAL")
> > > Signed-off-by: Breno Leitao <leitao@...ian.org>
> >
> > I don't think ec6d06efb0bac is to blame here, and CONFIG_DEBUG_VIRTUAL
> > is unsound in a number of places, so I'd prefer to remove that Fixes tag
> > and backport this for all stable trees.
>
> That is fair, thanks for the review.
>
> Should I submit a new version without the fixes tag, or, do you guys do
> it while merging the patch?
I assume that Catalin or Will can handle that when applying (if they
agree with me); no need to respin.
Mark.
Powered by blists - more mailing lists