[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNPiFxkZ6HPXYR0Xz0i=0p-ksEH4tC19fsj1fAwP1XkAjw@mail.gmail.com>
Date: Thu, 7 Nov 2024 16:46:57 +0100
From: Marco Elver <elver@...gle.com>
To: Steven Rostedt <rostedt@...dmis.org>
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 v2 1/2] tracing: Add task_prctl_unknown tracepoint
On Thu, 7 Nov 2024 at 16:34, Steven Rostedt <rostedt@...dmis.org> wrote:
...
> > + TP_PROTO(struct task_struct *task, int option, unsigned long arg2, unsigned long arg3,
> > + unsigned long arg4, unsigned long arg5),
> > +
> > + TP_ARGS(task, option, arg2, arg3, arg4, arg5),
> > +
> > + TP_STRUCT__entry(
> > + __string( comm, task->comm )
>
> The question is, do we really need comm? From your example, it's redundant:
>
> test-484 [000] ..... 631.748104: task_prctl_unknown: comm=test option=1234 arg2=101 arg3=102 arg4=103 arg5=104
> ^^^^ ^^^^
Ack, let's remove it. I will also remove the "task" argument.
Powered by blists - more mailing lists