[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231027183640.2529ab68@gandalf.local.home>
Date: Fri, 27 Oct 2023 18:36:40 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Beau Belgrave <beaub@...ux.microsoft.com>
Cc: Naresh Kamboju <naresh.kamboju@...aro.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
linux-trace-kernel@...r.kernel.org, lkft-triage@...ts.linaro.org,
Mark Brown <broonie@...nel.org>,
Zheng Yejian <zhengyejian1@...wei.com>,
Dan Carpenter <dan.carpenter@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
Zheng Yejian <zhengyejian1@...wei.com>
Subject: Re: selftests: user_events: ftrace_test - RIP:
0010:tracing_update_buffers (kernel/trace/trace.c:6470)
On Fri, 27 Oct 2023 12:20:11 -0700
Beau Belgrave <beaub@...ux.microsoft.com> wrote:
> On Fri, Oct 27, 2023 at 05:38:41PM +0530, Naresh Kamboju wrote:
> > Following kernel crash noticed on x86_64 while running selftests: user_events:
> > ftrace_test running 6.6.0-rc7-next-20231026.
> >
> > Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
> >
> > kselftest: Running tests in user_events
> > TAP version 13
> > 1..4
> > # timeout set to 90
> > # selftests: user_events: ftrace_test
> > [ 2391.606817] general protection fault, probably for non-canonical
> > address 0x6b6b6b6b6b6b8a83: 0000 [#1] PREEMPT SMP PTI
> > [ 2391.617519] CPU: 1 PID: 34662 Comm: ftrace_test Not tainted
> > 6.6.0-rc7-next-20231026 #1
> > [ 2391.625428] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> > 2.7 12/07/2021
> > [ 2391.632811] RIP: 0010:tracing_update_buffers (kernel/trace/trace.c:6470)
> > [ 2391.637952] Code: 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00
> > 55 31 f6 48 89 e5 41 55 41 54 53 48 89 fb 48 c7 c7 40 8c 61 94 e8 92
> > d3 5a 01 <44> 0f b6 a3 18 1f 00 00 41 80 fc 01 0f 87 c8 dc 4e 01 45 31
> Warning is from this code:
> static void __trace_array_put(struct trace_array *this_tr)
> {
> WARN_ON(!this_tr->ref);
> this_tr->ref--;
> }
>
> It seems like there might be a timing window or an incorrect call to
> trace_array_put() somewhere. Do you think this is related to the eventfs
> work?
No, I think this is was probably introduced by:
a1f157c7a3bb ("tracing: Expand all ring buffers individually")
Or possibly a mixture of the two changes? But anyway I think I need to look
at this one first.
-- Steve
Powered by blists - more mailing lists