Do not grab the `vmmaplk' recursively, prevent a self-deadlock.
authormpi <mpi@openbsd.org>
Tue, 25 Apr 2023 12:36:30 +0000 (12:36 +0000)
committermpi <mpi@openbsd.org>
Tue, 25 Apr 2023 12:36:30 +0000 (12:36 +0000)
commita4ddbf29eacf742b5ff96de79b141ca4b19db49b
tree5339de9cf4fa298ee9da8ba789f764812fb91995
parentb7da1a153c45053db93a1a5a85159166ccba93f0
Do not grab the `vmmaplk' recursively, prevent a self-deadlock.

Change the semantic of vm_map_busy() to be able to completely unlock the
`vmmaplk' instead of downgrading it to a read lock in mlock(2).  This is
necessary because uvm_fault_wire() tries to re-grab the same lock.

We now keep track of the thread currently holding the vmmap busy to ensure
it can relock & unbusy the vmmap.  The new pattern becomes:

....vm_map_lock(map);
....vm_map_busy(map); /* prevent other threads to grab an exclusive lock */
....vm_map_unlock(map);
....
..../*
.... * Do some stuff generally requiring a tsleep(9).
.... */
....
....vm_map_lock(map);
....vm_map_unbusy(map); /* allow other threads to make progress after unlock */
....vm_map_unlock(map);

Fix adapted from NetBSD's r1.249 of uvm/uvm_map.c.  Issue reported by
Jacqueline Jolicoeur exposed by a "wallet refresh" of the Monero App.
Panic hand-copied below:

sleep_finish()
rw_enter()
uvmfault_lookup()
uvm_fault_check()
uvm_fault()
uvm_fault_wire()
uvm_map_pageable_wire()
sys_mlock()

ok kettenis@
sys/uvm/uvm_map.c
sys/uvm/uvm_map.h