> On Oct 12, 2021, at 7:18 PM, Peter Xu <peterx@xxxxxxxxxx> wrote: > > 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..) Fair enough. Let me get back to you once I can provide more data. For now, I just ask you to have this patch in the back of your mind if any other change to userfaultfd syscall is proposed to prevent a potential conflict.
