On Mon, Oct 09, 2017 at 09:19:50AM +0300, Mike Rapoport wrote: > Indeed in CRIU we don't close the parent uffd and a couple of spurious > UFFD_EVENT_FORK won't cause a real problem. Yet, if we'll run out of file > descriptors because of signal flood during migration, even with graceful > failure we'd loose the migrated process entirely. That's precisely the problem. The only risk is file descriptor exhaustion. > Currently userfault related code in fork.c neatly fits into dup_mmap() and > moving the uffd structures up into the callers would be ugly :( Which is why for now I'm going to patch the selftest with a #define that can be undefined if the fork stops generating false positives. And this is needed only because the selftests cannot handle non cooperative workload, and for it, the spurious fork event is otherwise unexpected. You couldn't notice this with CRIU (unless the manager run out fds). > I'm going to experiment with the list of userfaultfd_ctx in mm_struct, it > seems to me that it may have additional value, e.g. to simplify > userfaultfd_event_wait_completion(). I'll need a bit of time to see if I'm > not talking complete nonsense :) Up to you, it's only a (minor) issue for non cooperative usage. > > diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c I'll submit the selftest fix after I split this up and submit it, but in the meantime if you work on this, to test any kernel change to the event fork, you can apply the patch I already sent and define those two: #define REPRODUCE_SPURIOUS_UFFD_EVENT_FORK_IN_SIG_TEST #define REPRODUCE_SPURIOUS_UFFD_EVENT_FORK_IN_EVENTS_TEST You'll reproduce the spurious fork events immediately with it. Perhaps the background signal flood can be slowed down a bit over time but it doesn't seem to slow down the workload too much, it starts and stops the signal flood (needed for immediate reproduction) every other second. Thanks, Andrea -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
