mm: lock vma explicitly before doing vm_flags_reset and vm_flags_reset_once
authorSuren Baghdasaryan <surenb@google.com>
Fri, 4 Aug 2023 15:27:22 +0000 (08:27 -0700)
committerAndrew Morton <akpm@linux-foundation.org>
Mon, 21 Aug 2023 20:37:46 +0000 (13:37 -0700)
commit60081bf19b0ec8fa40c589bd361fa2bc763f1050
treeb4c4909b23e49edc487efcd44d983fb2f2af6334
parente727bfd5e73a35ecbc4a01a15c659b9fafaa97c0
mm: lock vma explicitly before doing vm_flags_reset and vm_flags_reset_once

Implicit vma locking inside vm_flags_reset() and vm_flags_reset_once() is
not obvious and makes it hard to understand where vma locking is happening.
Also in some cases (like in dup_userfaultfd()) vma should be locked earlier
than vma_flags modification. To make locking more visible, change these
functions to assert that the vma write lock is taken and explicitly lock
the vma beforehand. Fix userfaultfd functions which should lock the vma
earlier.

Link: https://lkml.kernel.org/r/20230804152724.3090321-5-surenb@google.com
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: Jann Horn <jannh@google.com>
Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
arch/powerpc/kvm/book3s_hv_uvmem.c
fs/userfaultfd.c
include/linux/mm.h
mm/madvise.c
mm/mlock.c
mm/mprotect.c