On Tue, 5 Nov 2024 17:53:53 +0100 Marco Elver <[email protected]> wrote:
> > > +/** > > > + * task_prctl_unknown - called on unknown prctl() option > > > + * @task: pointer to the current task > > > + * @option: option passed > > > + * @arg2: arg2 passed > > > + * @arg3: arg3 passed > > > + * @arg4: arg4 passed > > > + * @arg5: arg5 passed > > > + * > > > + * Called on an unknown prctl() option. > > > + */ > > > +TRACE_EVENT(task_prctl_unknown, > > > + > > > + 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( > > > + __field( pid_t, pid ) > > > > Why record the pid that is already recorded by the event header? > > To keep in style with the other "task" tracepoints above. I can > certainly do without - it does seem unnecessary. Hmm, new_task, pid is different than the creator. But rename is pointless to record pid. I would get rid of it here, especially since it also creates a hole in the event (three int fields followed by a long). > > To cleanup, do we want to remove "pid=" from the other tracepoints in > this file as well (in another patch). Or does this potentially break > existing users? We can't from task_newtask as that's the pid of the task that's being created. In other words, it's very relevant. The task_rename could have its pid field dropped. > > > > + __string( comm, task->comm ) > > > > I'm also surprised that the comm didn't show in the trace_pipe. > > Any config options or tweaks needed to get it to show more reliably? > > > I've > > updated the code so that it should usually find it. But saving it here may > > not be a big deal. How did you start it? Because it appears reliable for me. -- Steve
