| created | 2023-05-22T09:39:21Z |
|---|---|
| begin | 2023-05-20T00:00:00Z |
| end | 2023-05-21T00:00:00Z |
| path | src/sys |
| commits | 2 |
| date | 2023-05-20T12:02:46Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/acpi/acpithinkpad.c | log | diff | annotate |
| message |
Implement battery charge control. ok patrick@ |
|||
| date | 2023-05-20T12:48:36Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/uvm/uvm_map.c | log | diff | annotate |
| src/sys/uvm/uvm_map.h | log | diff | annotate | |
| 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@ |
|||