On Wed, Oct 23, 2019 at 02:25:35PM -0700, Andy Lutomirski wrote: > That doesn't solve the problem. With your time machine, you should Would you elaborate what problem remains if execve closes all uffd so that read() cannot run post execve? > instead use ioctl() or recvmsg(). The event delivery is modeled after eventfd.c per userfaultfd.c header file, so would then eventfd also need to be converted to ioctl or recvmsg to deliver its event any better? Initially I evaluated to use eventfd for it in fact, but it wasn't possible. I didn't look like it could get any better than eventfd in terms of event delivery. Or do you refer to single out only the delivery of the UFFD_EVENT_FORK event not through read()? > > 4) enforce the global root permission check when creating the uffd only if > > UFFD_FEATURE_EVENT_FORK is set. > > This could work, but we should also add a better way to do > UFFD_FEATURE_EVENT_FORK and get CRIU to start using it. If CRIU is > the only user, we can probably drop the old ABI after a couple of > releases, since as far as I know, CRIU users need to upgrade their > CRIU more or less in sync with the kernel so that new kernel features > get checkpointed and restored. Getting CRIU stat using it shouldn't be a problem at all, but we'll be back to square one if you just stop there. I don't see how to lift those limitations in the wiki to make it usable in production by just providing a better way to do UFFD_FEATURE_EVENT_FORK. If you're volunteering to fix the limitations and make CRIU usable in production that would be awesome, then of course we should do whatever possible to improve UFFD_FEATURE_EVENT_FORK. Thanks, Andrea
