[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250121143926.4da664b4@gandalf.local.home>
Date: Tue, 21 Jan 2025 14:39:26 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Sasha Levin <sashal@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, LKML
<linux-kernel@...r.kernel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Alice Ryhl
<aliceryhl@...gle.com>
Subject: Re: [GIT PULL v2] tracing: Updates for v6.14
On Tue, 21 Jan 2025 14:11:27 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:
> On Tue, 21 Jan 2025 14:09:02 -0500
> Sasha Levin <sashal@...nel.org> wrote:
>
> > >Let's see if your config makes that different.
> >
> > Hmm... LKFT reproduces it fairly easily even on -next. From the log, it
> > looks like it reproduces under LTP's read_all_sys test.
>
> I'm able to reproduce it with random writes into set_event and then running
> "trace-cmd stat" which does a lot of reads of tracefs.
>
> I re-enabled KASAN and kmemleak to see if it gives a hint to what is going wrong.
>
Bah! I found it.
static void *s_start(struct seq_file *m, loff_t *pos)
{
- struct trace_event_file *file;
struct trace_array *tr = m->private;
+ struct set_event_iter *iter;
loff_t l;
+ iter = kzalloc(sizeof(iter), GFP_KERNEL);
^^^^^
Should be (*iter) :-p
+ if (!iter)
+ return NULL;
+
I caught this before I pushed this to linux-next and I thought I fixed it.
No idea how the older version made it out to linux-next and my pull request.
I tested the fixed version, but sent out the broken one! I was also
updating my test suite at the time, so I may have screwed something up in
my workflow.
Since this is already out, I'll send a separate fix to it. Thanks for
reporting.
-- Steve
Powered by blists - more mailing lists