diff options
| author | Jann Horn <jannh@google.com> | 2023-08-15 23:22:16 +0200 |
|---|---|---|
| committer | Andrew Morton <akpm@linux-foundation.org> | 2023-08-25 01:20:27 +0200 |
| commit | 004a9a38e20da6eb88fbfb7eeff0f3dd8a01776a (patch) | |
| tree | 2346a5f6090ae5483c243080d7d0ae03de305503 /fs/userfaultfd.c | |
| parent | arm64: mm: use ptep_clear() instead of pte_clear() in clear_flush() (diff) | |
| download | linux-004a9a38e20da6eb88fbfb7eeff0f3dd8a01776a.tar.xz linux-004a9a38e20da6eb88fbfb7eeff0f3dd8a01776a.zip | |
mm: userfaultfd: remove stale comment about core dump locking
Since commit 7f3bfab52cab ("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/20230815212216.264445-1-jannh@google.com
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'fs/userfaultfd.c')
| -rw-r--r-- | fs/userfaultfd.c | 6 |
1 files changed, 1 insertions, 5 deletions
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 1091cb461747..56eaae9dac1a 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -428,15 +428,11 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason) * FOLL_DUMP case, anon memory also checks for FOLL_DUMP with * the no_page_table() helper in follow_page_mask(), but the * shmem_vm_ops->fault method is invoked even during - * coredumping without mmap_lock and it ends up here. + * coredumping and it ends up here. */ if (current->flags & (PF_EXITING|PF_DUMPCORE)) goto out; - /* - * Coredumping runs without mmap_lock so we can only check that - * the mmap_lock is held, if PF_DUMPCORE was not set. - */ assert_fault_locked(vmf); ctx = vma->vm_userfaultfd_ctx.ctx; |