Skip to content
  • Andrea Arcangeli's avatar
    userfaultfd: allow signals to interrupt a userfault · dfa37dc3
    Andrea Arcangeli authored
    
    
    This is only simple to achieve if the userfault is going to return to
    userland (not to the kernel) because we can avoid returning VM_FAULT_RETRY
    despite we temporarily released the mmap_sem.  The fault would just be
    retried by userland then.  This is safe at least on x86 and powerpc (the
    two archs with the syscall implemented so far).
    
    Hint to verify for which archs this is safe: after handle_mm_fault
    returns, no access to data structures protected by the mmap_sem must be
    done by the fault code in arch/*/mm/fault.c until up_read(&mm->mmap_sem)
    is called.
    
    This has two main benefits: signals can run with lower latency in
    production (signals aren't blocked by userfaults and userfaults are
    immediately repeated after signal processing) and gdb can then trivially
    debug the threads blocked in this kind of userfaults coming directly from
    userland.
    
    On a side note: while gdb has a need to get signal processed, coredumps
    always worked perfectly with userfaults, no matter if the userfault is
    triggered by GUP a kernel copy_user or directly from userland.
    
    Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
    Cc: Pavel Emelyanov <xemul@parallels.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    dfa37dc3