Hi Linus, > But it sounds like your JIT case actually uses it for writing - > but if you can write a small blurb about it, that would be nice.
yes, we use it for writing. Happy to describe the scheme in more detail. > (b) it would probably be nice to limit FOLL_FORCE in general as much > as possible, so if your case is about writing to your very _own_ > memory mapping, as opposed to writing to another process' memory, > maybe we can do something like > > if (mm == current->mm) > flags |= FOLL_FORCE; > > which at least avoids the whole "let's change the VM in odd ways for a > process that isn't even me". While this would fix our current use case, we do have a use case for modifying non-local address space as well (putting the JIT into a different process). Similarly, the rr use case precisely uses the remote mm case. I think in general this feature is very useful for anybody who needs to precisely control the execution of some other process. Various debuggers (gdb/lldb/rr) certainly fall into that category, but there's another class of such processes (wine, various emulators) which may want to do that kind of thing. Now, I suspect most of these will have the other process under ptrace control, so maybe allowing (same_mm || ptraced) would be ok, but at least for the sandbox/remote-jit use case, it would be perfectly reasonable to not have the jit server be a ptracer.
