On 2020-04-27, Christian Brauner <christian.brauner@xxxxxxxxxx> wrote: > On Mon, Apr 27, 2020 at 10:08:03PM +0200, Arnd Bergmann wrote: > > The way I understood Jann was that instead of a new syscall that duplicates > > everything in ptrace(), there would only need to be a new ptrace request > > such as PTRACE_ATTACH_PIDFD that behaves like PTRACE_ATTACH > > but takes a pidfd as the second argument, perhaps setting the return value > > to the pid on success. Same for PTRACE_SEIZE. > > That was my initial suggestion, yes. Any enum that identifies a target > by a pid will get a new _PIDFD version and the pidfd is passed as pid_t > argument. That should work and is similar to what I did for waitid() > P_PIDFD. Realistically, there shouldn't be any system where pid_t is > smaller than an int that we care about. > > > In effect this is not much different from your a), just a variation on the > > calling conventions. The main upside is that it avoids adding another > > ugly interface, the flip side is that it makes the existing one slightly worse > > by adding complexity. > > Basically, if a new syscall than please a proper re-design with real > benefits. > > In the meantime we could make due with the _PIDFD variant. And then if > someone wants to do the nitty gritty work of adding a ptrace variant > purely based on pidfds and with a better api and features that e.g. Jann > pointed out then by all means, please do so. I'm sure we would all > welcome this as well. I agree. It would be a shame to add a new ptrace syscall and not take the opportunity to fix the multitude of problems with the existing API. But that's a Pandora's box which we shouldn't open unless we want to wait a long time to get an API everyone is okay with -- a pretty high price to just get pidfds support in ptrace. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
