Skip to content

Commit 004a9a3

Browse files
thejhakpm00
authored andcommitted
mm: userfaultfd: remove stale comment about core dump locking
Since commit 7f3bfab ("mm/gup: take mmap_lock in get_dump_page()"), which landed in v5.10, core dumping doesn't enter fault handling without holding the mmap_lock anymore. Remove the stale parts of the comments, but leave the behavior as-is - letting core dumping block on userfault handling would be a bad idea and could lead to deadlocks if the dumping process was handling its own userfaults. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
1 parent 00de2c9 commit 004a9a3

File tree

1 file changed

+1
-5
lines changed

1 file changed

+1
-5
lines changed

fs/userfaultfd.c

Lines changed: 1 addition & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -428,15 +428,11 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason)
428428
* FOLL_DUMP case, anon memory also checks for FOLL_DUMP with
429429
* the no_page_table() helper in follow_page_mask(), but the
430430
* shmem_vm_ops->fault method is invoked even during
431-
* coredumping without mmap_lock and it ends up here.
431+
* coredumping and it ends up here.
432432
*/
433433
if (current->flags & (PF_EXITING|PF_DUMPCORE))
434434
goto out;
435435

436-
/*
437-
* Coredumping runs without mmap_lock so we can only check that
438-
* the mmap_lock is held, if PF_DUMPCORE was not set.
439-
*/
440436
assert_fault_locked(vmf);
441437

442438
ctx = vma->vm_userfaultfd_ctx.ctx;

0 commit comments

Comments
 (0)