[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241106173023.09322117@gandalf.local.home>
Date: Wed, 6 Nov 2024 17:30:23 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Marco Elver <elver@...gle.com>
Cc: Kees Cook <keescook@...omium.org>, Masami Hiramatsu
<mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Andrew Morton <akpm@...ux-foundation.org>, Oleg Nesterov <oleg@...hat.com>,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, Dmitry
Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com
Subject: Re: [PATCH] tracing: Add task_prctl_unknown tracepoint
On Wed, 6 Nov 2024 22:59:25 +0100
Marco Elver <elver@...gle.com> wrote:
> On Wed, 6 Nov 2024 at 22:23, Steven Rostedt <rostedt@...dmis.org> wrote:
> ...
> > > That's pretty much it. I've attached my kernel config just in case I
> > > missed something.
> >
> > OK, it's because you are using trace_pipe (which by the way should not be
> > used for anything serious). The read of trace_pipe flushes the buffer
> > before the task is scheduled out and the comm saved, so it prints the
> > "<...>". If you instead do the cat of trace_pipe *after* running the
> > command, you'll see the comm.
> >
> > So this is just because you are using the obsolete trace_pipe.
>
> I see, thanks for clarifying. I always felt for quick testing it
> serves its purpose - anything equally simple you recommend for testing
> but doesn't suffer from this problem?
You can run trace-cmd, or cat trace after the run.
-- Steve
Powered by blists - more mailing lists