LWN: Comments on "Adding the pidfd abstraction to the kernel"

Adding the pidfd abstraction to the kernel

zse — Fri, 29 Nov 2019 12:02:09 +0000

There might be a use case for pidfds referring to an individual thread: Currently, audio applications that want a thread to run with real-time priorities have to send a request (containing the kernel thread id of the target thread) to the RealtimeKit daemon. That looks like the same race condition to me.

Adding the pidfd abstraction to the kernel

nix — Sun, 13 Oct 2019 16:16:01 +0000

This is not just useful for multiple ptracers: it is also useful if you have a thread that wants to ptrace a victim on behalf of other threads in the tracing process. For that, you need a pollable fd that at least trips something pollable (POLLIN, say) when the victim wants attention, so that you can also poll on message pipes etc from the rest of the process. I implemented this for DTrace by reviving the old RH waitfd(), but it was really crocky compared to pidfds and I'd much rather use those.

But we can't use those as long as waitid is used -- as I discovered to my cost in the waitfd implementation waitid destroys a bunch of info that waitpid returns (IIRC, the high bits of the return code, but my memory of this was faded) and which is crucial for ptrace. There's a reason all the ptrace examples use waitpid rather than waitid... a shame, because the waitid API is ever so much nicer than waitpid. (Alternatively, waitid could be fixed so it was usable to accept ptrace results -- but that seems likely to be quite difficult!)

Adding the pidfd abstraction to the kernel

mjw — Wed, 09 Oct 2019 18:14:38 +0000

> I'd like to be able to use strace and gdb on a process at the same time.

There is a patch for that: https://lists.strace.io/pipermail/strace-devel/2019-Septe...

Adding the pidfd abstraction to the kernel

scientes — Wed, 09 Oct 2019 15:42:18 +0000

I'd like to be able to use strace and gdb on a process at the same time.

Adding the pidfd abstraction to the kernel

roc — Wed, 09 Oct 2019 00:20:53 +0000

(without detaching)

Adding the pidfd abstraction to the kernel

roc — Wed, 09 Oct 2019 00:20:21 +0000

For my purposes it would be adequate to allow just one ptracer at a time. The problem is that right now there is no way to hand off ptrace ownership from one process to another.

Adding the pidfd abstraction to the kernel

NYKevin — Tue, 08 Oct 2019 22:22:04 +0000

ptrace() is a debugger interface, not a general-purpose API. If the end user really wants to attach two debuggers to the same process and send them off to the races, well, why not just let them do it? They're a programmer, they should know better.

Adding the pidfd abstraction to the kernel

acarno — Tue, 08 Oct 2019 17:22:40 +0000

> eliminates the current restriction that a task can have just one unique ptracer process

Given that ptrace() allows the tracing process to manipulate the traced process, would this generate race conditions? I feel like you'd need to define a "read-only" context to allow multiple ptracer processes.

Adding the pidfd abstraction to the kernel

hupstream — Tue, 08 Oct 2019 12:03:25 +0000

Here is the link for this talk (Kernel Recipes 2019): https://youtu.be/19SlR_zjPxc

Adding the pidfd abstraction to the kernel

roc — Tue, 08 Oct 2019 02:33:26 +0000

> There do not appear to be any use cases for pidfds that refer to an individual thread for now;

ptrace() would need this.

It would be great if ptrace() supported pidfds in a way that eliminates the current restriction that a task can have just one unique ptracer process *and* that ptracer cannot be changed without detaching and reattaching, i.e., so it became possible to hand off ptrace control to another ptracer process.