On 04/09/20 21:19, Florian Weimer wrote: > I'm not sure what the advantage is of returning separate file > descriptors, and nit operating directly on the pidfd. For privilege separation. So far, the common case of pidfd operations has been that whoever possesses a pidfd has "power" over the target process. Here however we also want to cover the case where one privileged process wants to set up and manage a memory range for multiple children. The privilege process can do so by passing the access file descriptor via SCM_RIGHTS. We also want different children to have visibility over different ranges, which is why there are multiple control fds rather than using the pidfd itself as control fd. You could have the map/unmap/lock ioctl on the pidfd itself and the access fd as an argument of the ioctl, but it seems cleaner to represent the pidfd-mem control capability as its own file descriptor. Paolo
