utrace and thread termination

[Stephane Eranian]

Roland,

On Tue, Nov 13, 2007 at 06:04:02PM -0800, Roland McGrath wrote:
> Inside the kernel, you can use utrace for this.  At the moment, there is no
> new canonical user-level interface that hooks into the utrace facilities.

Yes, I would need this at the user level for monitoring tools to detect
termination of monitored threads.


> So if you are looking for a replacement for ptrace in that sense, the
> utrace layer per se does not fulfill that role by itself.
> 
I think monitoring tools would need only a subset of what ptrace does:
	1/ ability to stop another thread and have the guarantee that upon
	  return from the syscall, the thread is actually off the CPU.

	2/ ability to detach and resume execution

	3/ ability to get notifications on:
		- fork, vfork
		- exec
		- exit
		- pthread_create
		- termination (different from exit: guarantee thread is off CPU)
	  
I know that ptrace already provides 1/, 2/, 3/ and in fact I am using this today
in pfmon. But I don't like the ther side effects such as signal forwarding.

Another property of ptrace() that we leverage is the fact that there can only be
one ptracing parent. When operating on a monitored thread's PMU state, we need
that thread stopped, thus ptrace_check_attach(). But we also need to guarantee
that nobody can wakeup the thread (kill -CONT for instance) while we operate on
it.

> If you already have your own kernel code and a sufficient way for it to
> communicate with user-level (e.g. whatever you use for monitor events),
> then it is simple to use utrace in that kernel code to give a callback when
> the thread is dying.  Since I imagine you already have your own per-thread
> context in the kernel for perfmon and some hook by which to clean it up,
> this may not be buying you anything at all.
> 
> Depending what you need, utrace too might be overkill.  It avoids many
> important drawbacks of ptrace, but it does entail more complexity than
> might be warranted for something really basic.  What utrace gives you is
> synchronous notification, i.e. instant and with some possibility to
> interlock with other bookkeeping before the process could be reaped (and
> its PID reused if you don't have other get_task_struct refs on it).  If you
> don't need that, there may be other options already in the upstream kernel.
> For example, there is "connector", though AFAICT that only lets you ask for
> all thread deaths across the whole system.  There might be some sort of
> /proc polling or inotify or something that works (I haven't looked into that).
> 
Somebody suggested inotify. I tired that yesterday and it does not work on
/proc files because they are generated on demand, too bad. Maybe this is 
something that could be extended. I'll ask robert love (author of inotify).

Thanks for your detailed answer.

-- 

-Stephane