process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 21, 2020 15:50 UTC (Tue) by cyphar (subscriber, #110703)
Parent article: process_madvise(), pidfd capabilities, and the revenge of the PIDs

> In this moment the tracer knows everything about tracee state, and pidfd brackets pidfd_open() and close() around actual action look just stupid, and this is cpu time wasting.

While I do understand wanting to maintain support for PIDs in newer syscalls (after all, in some cases you only get a PID from a user or other program), I don't think that a tracer program would be written in the way described. It's far more likely that the tracer would already have a pidfd open for each process it is tracing. But then again, since ptrace (and ptrace-related syscalls) doesn't use pidfds, it would also be fair to say that the interface mismatch would make the code ugly no matter what.

process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 21, 2020 19:32 UTC (Tue) by rvolgers (guest, #63218) [Link] (4 responses)

If ever there was a good use case for pidfd's it's ptrace. That is one ugly interface, with all the signal magic and pseudo-reparenting.

Of course, porting it would take quite a lot of effort probably, nevermind deprecating the old interface so all the cruft can be removed, but one can dream.

process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 21, 2020 19:52 UTC (Tue) by roc (subscriber, #30627) [Link]

Maybe hack pidfds into ptrace and other syscalls by passing "-pidfd" as the pid?

process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 21, 2020 19:58 UTC (Tue) by roc (subscriber, #30627) [Link] (2 responses)

I think pidfds for ptrace() would be good, but I don't think they immediately solve the major issues with ptrace.

I would really like the ability to hand-off ptrace control to other processes by passing them a pidfd, but that would require lots more work. Something like:
* Make sure pidfd_wait or whatever can read the special ptrace status events.
* When pidfds are used, break the "ptrace parent" relationship in the kernel so *any* process with a pidfd for the tracee can ptrace() it or get the ptrace status events. (I bet this is *really* hard.)
But it would make much-requested rr features, like the ability to start debugging an in-progress rr recording without interrupting it, much more tractable.

process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 21, 2020 22:52 UTC (Tue) by Paf (subscriber, #91811) [Link] (1 responses)

Why do you think breaking the ptrace parent relationship would be so hard?

I’m not really familiar with that part of ptrace, but I have had to look at the signal handling dance and it is a *mess*. (Not incorrect in any way, just... messy)

process_madvise(), pidfd capabilities, and the revenge of the PIDs

Posted Jan 22, 2020 2:44 UTC (Wed) by roc (subscriber, #30627) [Link]

The current ptrace code is designed around that relationship, and I assume that any significant changes to ptrace code are going to be hard. I'd love to be wrong!