• A
    userfaultfd: allow signals to interrupt a userfault · dfa37dc3
    Andrea Arcangeli 提交于
    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: NAndrea 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: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    dfa37dc3
userfaultfd.c 34.3 KB