On Sun, Sep 26, 2021 at 10:06:37AM -0700, Nadav Amit wrote: > From: Nadav Amit <namit@xxxxxxxxxx> > > Non-cooperative mode is useful but only for forked processes. > Userfaultfd can be useful to monitor, debug and manage memory of remote > processes. > > To support this mode, add a new flag, UFFD_REMOTE_PID, and an optional > second argument to the userfaultfd syscall. When the flag is set, the > second argument is assumed to be the PID of the process that is to be > monitored. Otherwise the flag is ignored. > > The syscall enforces that the caller has CAP_SYS_PTRACE to prevent > misuse of this feature. > > Cc: Andrea Arcangeli <aarcange@xxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: Mike Rapoport <rppt@xxxxxxxxxxxxxxxxxx> > Cc: Peter Xu <peterx@xxxxxxxxxx> > Signed-off-by: Nadav Amit <namit@xxxxxxxxxx> I think this patch from one pov looks just likes the other patch of the process_madvise on DONTNEED - the new interface definitely opens new way to do things, however IMHO it would be great to discuss some detailed scenario that we can do with it better than the existing facilities. The thing is uffd already provides some mechanism for doing things like customized swapping, so that's not something new IMHO that this patch brings (neither is what the DONTNEED patch brings), just like when I raised in the other thread about umap. So IMHO it'll be great if there can be some elaboration on how the "remote" capability could help us do things better (e.g., use cases that we may not solve with linking against another uffd-supported library, or we can't do with register uffd then fork()). (I skipped the security side of things, as I replied in the other thread that I think I buy in your point on depending on PTRACE capability and also the examples you gave on ptrace() and process_vm_writev() are persuasive to me, but no expert on that..) Thanks, -- Peter Xu
