Thread (12 messages) 12 messages, 2 authors, 2024-11-06

Re: [PATCH] tracing: Add task_prctl_unknown tracepoint

From: Marco Elver <elver@google.com>
Date: 2024-11-06 18:12:51
Also in: lkml

On Wed, Nov 06, 2024 at 10:28AM -0500, Steven Rostedt wrote:
On Wed, 6 Nov 2024 10:18:23 -0500
Steven Rostedt [off-list ref] wrote:
quoted
quoted
Some trial and error led me to conclude it's a race between the logic
looking up the comm and the process exiting: If the test program exits
soon after the traced event, it doesn't print the comm. Adding a
generous usleep() before it exits reliably prints the comm.  
Thanks for letting me know. Let me see if I can fix that!
Hmm, that still doesn't make sense. Is this just a single line or do you
have other events being recorded?

The way the caching works is during the sched_switch tracepoint which still
gets called when the task exits. If a trace event is triggered, it sets a
per cpu flags to have the next sched_switch record the comm for both the
previous and next tasks.

Now the reason it can miss is that there's contention on the lock that
saves the comms (it does a trylock and if it fails, it just skips it). Or
if another task hits the same "comm cache line".

This is why I wonder if you have other events being traced.
No other events should be traced. This is the test program I've used:

	#include <sys/prctl.h>
	#include <unistd.h>

	int main(int argc, char *argv[])
	{
	  prctl(1234, 101, 102, 103, 104);
	  if (argc > 1)
	    usleep(1000);
	  return 0;
	}

Kernel config is x86_64 default + CONFIG_FUNCTION_TRACER=y +
CONFIG_FTRACE_SYSCALLS=y. For the test, once booted all I do is:

	% echo 1 > /sys/kernel/debug/tracing/events/task/task_prctl_unknown/enable
	% cat /sys/kernel/debug/tracing/trace_pipe
	... wait for output ...

That's pretty much it. I've attached my kernel config just in case I
missed something.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help