CVSROOT: /cvs
Module name: src
Changes by: m...@cvs.openbsd.org 2023/05/20 06:48:36
Modified files:
sys/uvm : uvm_map.c uvm_map.h
Log message:
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()
This version skips bumping the map's timestamp if the lock is acquired by the
thread marked the VM map busy. This prevents a KASSERT() reported by bluhm@
triggered by regress/misc/posixtestsuite conformance/interfaces/mmap/18-1
ok kettenis@
