On Tue, 5 Nov 2024 17:53:53 +0100
Marco Elver [off-list ref] wrote:

quoted

quoted

+/**
+ * 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.

quoted

quoted

+             __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?

quoted

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