From: Russell King <linux@armlinux.org.uk>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
linux-perf-users@vger.kernel.org, loongarch@lists.linux.dev,
Mark Rutland <mark.rutland@arm.com>,
Ian Rogers <irogers@google.com>,
Peter Zijlstra <peterz@infradead.org>,
"Luis Claudio R. Goncalves" <lgoncalv@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
James Clark <james.clark@linaro.org>,
Huacai Chen <chenhuacai@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Oleg Nesterov <oleg@redhat.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Waiman Long <longman@redhat.com>, WANG Xuerui <kernel@xen0n.name>,
Will Deacon <will@kernel.org>,
Clark Williams <clrkwllms@kernel.org>
Subject: Re: [PATCH v2] ARM, ARM64, LONGARCH: Delay HW BP notification to task_work()
Date: Tue, 8 Sep 2026 13:47:25 +0100 [thread overview]
Message-ID: <aqAD3YubuHDy8Fva@shell.armlinux.org.uk> (raw)
In-Reply-To: <20260908093826.ofGxmRRK@linutronix.de>
On Tue, Sep 08, 2026 at 11:38:26AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-09-08 09:43:43 [+0100], Russell King wrote:
> > > > > The linked report shows a backtrace by "BUG: sleeping function"
> > > > > originating from el0_breakpt() -> perf_bp_event() following by sending a
> > > > > signal force_sig_fault() followed by rt_spin_lock() and
> > > > > __might_resched(). It also contains a reproducer.
> > > > >
> > > > > The first sentence has the part
> > > > > | The hardware event is
> > > > > | delivered with disabled interrupts and perf intrastrucure expects
> > > > > | disabled interrupts while the overflow callback is invoked.
> > > >
> > > > *Where* are interrupts disabled?
> > >
> > > On exception entry point, that would el0t_64_sync() for arm64 as in the
> > > report.
> >
> > Oh FFS. So why does this need to be done on ARM? Explain it. This is
> > what I'm trying to get out of you, but you're being very resistant
> > to providing the technical details. I can only think you haven't
> > actually done the analysis.
>
> I had the feeling that this is not what you were expecting but I wasn't
> sure what you were expecting either.
>
> The hardware breakpoint is delivered to the OS via an exception and on
> exception entry point the interrupts are disabled. This isn't unique to
> ARM but the same on other architectures, too.
Yes, architecturally, when the CPU enters an exception handler,
interrupts are disabled by the CPU. However, that doesn't translate
to "the kernel runs with interrupts disabled". In most cases, we
re-enable interrupts if the exception comes from userspace.
However, I have no idea where in the call path is between the
exception being entered and the code you have a problem with - and
I've now forgotten where to find the call path, and I don't have
time to find it again. You are making this incredibly difficult,
and I don't have time for this. Sorry, this is my last reply for
a while, because this is just too much stress at this time for me.
What was a simple request has turned into a major source of frustration.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
prev parent reply other threads:[~2026-09-08 12:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 8:51 Sebastian Andrzej Siewior
2026-08-14 9:03 ` sashiko-bot
2026-08-14 9:20 ` Sebastian Andrzej Siewior
2026-09-03 15:47 ` Luis Claudio R. Goncalves
2026-09-03 16:07 ` Sebastian Andrzej Siewior
2026-09-03 16:47 ` Russell King
2026-09-03 17:31 ` Steven Rostedt
2026-09-04 15:54 ` Sebastian Andrzej Siewior
2026-09-07 14:46 ` Russell King
2026-09-08 7:54 ` Sebastian Andrzej Siewior
2026-09-08 8:00 ` Russell King
2026-09-08 8:37 ` Sebastian Andrzej Siewior
2026-09-08 8:43 ` Russell King
2026-09-08 9:38 ` Sebastian Andrzej Siewior
2026-09-08 12:47 ` Russell King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqAD3YubuHDy8Fva@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=bigeasy@linutronix.de \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=clrkwllms@kernel.org \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=kernel@xen0n.name \
--cc=lgoncalv@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=longman@redhat.com \
--cc=loongarch@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®