From: Bert Karwatzki <spasswolf@web•de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix•de>,
Steven Rostedt <rostedt@goodmis•org>
Cc: linux-kernel@vger•kernel.org, linux-next@vger•kernel.org,
bpf@vger•kernel.org, linux-rt-users@vger•kernel.org,
linux-rt-devel@lists•linux.dev,
Thomas Gleixner <tglx@linutronix•de>,
Alexei Starovoitov <alexei.starovoitov@gmail•com>,
spasswolf@web•de
Subject: Re: BUG: scheduling while atomic with PREEMPT_RT=y and bpf selftests
Date: Sun, 08 Jun 2025 10:45:36 +0200 [thread overview]
Message-ID: <0b1f48ba715a16c4d4874ae65bc01914de4d5a90.camel@web.de> (raw)
In-Reply-To: <20250605125133.RSTingmi@linutronix.de>
Am Donnerstag, dem 05.06.2025 um 14:51 +0200 schrieb Sebastian Andrzej Siewior:
> On 2025-06-05 08:48:38 [-0400], Steven Rostedt wrote:
> > On Thu, 5 Jun 2025 11:19:03 +0200
> > Bert Karwatzki <spasswolf@web•de> wrote:
> >
> > > This patch seems to create so much output that the orginal error message and
> > > backtrace often get lost, so I needed several runs to get a meaningful message
> > > when running
> >
> > Are you familiar with preempt count tracing?
>
> I have an initial set of patches to tackle this problem, I'm going to
> send them after the merge window.
>
> Sebastian
I've found the reason for the "mysterious" increase of preempt_count:
[ 70.821750] [ T2746] bpf_link_settle calling fd_install() preemt_count = 0
[ 70.821751] [ T2746] preempt_count_add 5898: preempt_count = 0x0 counter = 0x1b232c
[ 70.821752] [ T2746] preempt_count_add 5900: preempt_count = 0x1 counter = 0x1b232d
[ 70.821754] [ T2746] preempt_count_sub 5966: preempt_count = 0x1 counter = 0x1b232e
[ 70.821755] [ T2746] preempt_count_sub 5968: preempt_count = 0x0 counter = 0x1b232f
[ 70.821761] [ T2746] __bpf_trace_sys_enter 18: preempt_count = 0x0
[ 70.821762] [ T2746] __bpf_trace_sys_enter 18: preempt_count = 0x1
[ 70.821764] [ T2746] __bpf_trace_run: preempt_count = 1
[ 70.821765] [ T2746] bpf_prog_run: preempt_count = 1
[ 70.821766] [ T2746] __bpf_prog_run: preempt_count = 1
It's caused by this macro from include/trace/bpf_probe.h (with my pr_err()):
#define __BPF_DECLARE_TRACE_SYSCALL(call, proto, args) \
static notrace void \
__bpf_trace_##call(void *__data, proto) \
{ \
might_fault(); \
if (!strcmp(get_current()->comm, "test_progs")) \
pr_err("%s %d: preempt_count = 0x%x", __func__, __LINE__, preempt_count());\
preempt_disable_notrace(); \
if (!strcmp(get_current()->comm, "test_progs")) \
pr_err("%s %d: preempt_count = 0x%x", __func__, __LINE__, preempt_count());\
CONCATENATE(bpf_trace_run, COUNT_ARGS(args))(__data, CAST_TO_U64(args)); \
preempt_enable_notrace(); \
}
The preempt_{en,dis}able_notrace were introduced in
commit 4aadde89d81f ("tracing/bpf: disable preemption in syscall probe")
This commit is present in v6.14 and v6.15, but the bug already appears in
v6.12 so in that case preemption is disable somewhere else.
Bert Karwatzki
next prev parent reply other threads:[~2025-06-08 8:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 9:19 BUG: scheduling while atomic with PREEMPT_RT=y and bpf selftests Bert Karwatzki
2025-06-05 12:48 ` Steven Rostedt
2025-06-05 12:51 ` Sebastian Andrzej Siewior
2025-06-08 8:45 ` Bert Karwatzki [this message]
2025-06-08 15:53 ` Bert Karwatzki
2025-06-09 11:37 ` Bert Karwatzki
2025-06-14 12:01 ` Bert Karwatzki
2025-06-15 22:12 ` Bert Karwatzki
2025-06-16 6:28 ` Sebastian Andrzej Siewior
2025-06-06 13:13 ` Bert Karwatzki
2025-06-06 13:57 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2025-05-25 22:47 Bert Karwatzki
2025-05-26 1:32 ` Alexei Starovoitov
2025-05-26 9:22 ` Bert Karwatzki
2025-05-27 7:19 ` Sebastian Andrzej Siewior
2025-05-25 12:14 Bert Karwatzki
2025-05-25 11:54 Bert Karwatzki
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=0b1f48ba715a16c4d4874ae65bc01914de4d5a90.camel@web.de \
--to=spasswolf@web$(echo .)de \
--cc=alexei.starovoitov@gmail$(echo .)com \
--cc=bigeasy@linutronix$(echo .)de \
--cc=bpf@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=linux-rt-devel@lists$(echo .)linux.dev \
--cc=linux-rt-users@vger$(echo .)kernel.org \
--cc=rostedt@goodmis$(echo .)org \
--cc=tglx@linutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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