kern/56911: uvm_vslock fails to block munmap

[campbell+netbsd%mumble.net@localhost]

>Number:         56911
>Category:       kern
>Synopsis:       uvm_vslock fails to block munmap
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 04 16:25:00 +0000 2022
>Originator:     Taylor R Campbell
>Release:        NetBSD-current
>Organization:
Th NtBSD Fndtn
>Environment:
ruled unconstitutional by SCOTUS, 6-3
>Description:
Some kernel systems -- such as genfs_directio, mincore(2), and MI _ucas_32/_ucas_64 -- rely on uvm_vslock to lock virtual address mappings to physical pages, so that, e.g., pmap_extract will succeed:

https://nxr.netbsd.org/xref/src/sys/miscfs/genfs/genfs_io.c?r=1.102#1916

uvm_vslock does prevent the pages from being swapped.  However, it does not prevent concurrent munmap(2) from unmapping them, or concurrent mremap(2) from remapping them.
>How-To-Repeat:
munmap (or mmap, or mremap) a virtual address range concurrently with a read/write on a file opened O_DIRECT, or concurrently with mincore(2), or concurrently with futex(2).

Example crashes with reproducer: https://syzkaller.appspot.com/bug?id=f82f8fba49a7138ffc83001e6ca9a19d6d9c4955
>Fix:
Yes please!

mmap/munmap/mremap must block until the virtual address range in question is released by uvm_vsunlock.  This should be a reasonably short duration -- unless uvm_vslock is blocking waiting for swapping -- because once the pages are locked no more I/O should be happening.