On Jul 19, 2022, at 7:32 PM, Peter Xu peterx@redhat.com wrote:
⚠ External Email
On Tue, Jul 19, 2022 at 11:55:21PM +0000, Nadav Amit wrote:
Anyhow, I do want to clarify a bit about the “cross-process support” userfaultfd situation. Basically, you can already get cross-process support today, by using calling userfaultfd() on the controlled process and calling pidfd_open() from another process. It does work and I do not remember any issues that it introduced (in contrast, for instance, to io-uring, that would break if you use userfaultfd+iouring+fork today).
Do you mean to base it on pidof_getfd()?
autocorrect? :)
I did refer to pidfd_getfd() as a syscall that can be used today by one process to control the address space of another process. I did not intend to use it for the actual implementation.
Just want to mention that this will still need collaboration of the target process as userfaultfd needs to be created explicitly there. From that POV it's still more similar to general SCM_RIGHTS trick to pass over the fd but just to pass it in a different way.
There are also some tricks you can do with ptrace in order not to need the collaboration, but they are admittedly fragile.
IMHO the core change about having /proc/pid/userfaultfd is skipping that only last step to create the handle.
Yes. The point that I was trying to make is that there are no open issues with adding support for remote process control through /proc/pid/userfaultfd. This is in contrast, for example, for using io-uring with userfaultfd. For instance, if you try to use io-uring TODAY with userfaultfd (without the async support that I need to add), and you try to monitor the fork event, things would break (the new userfaultfd file descriptor after fork would be installed on the io-worker thread).
This is all to say that it is really simple to add support for one process monitoring userfaultfd of another process, since I understood that Axel had concerned that this might be utterly broken…