On Sun, Oct 20, 2024 at 05:28:17AM -0600, David Gwynne wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: [email protected] 2024/10/20 05:28:17
>
> Modified files:
> sys/uvm : uvm_map.c uvm_map.h
>
> Log message:
> try to simplify the locking code around busy maps.
>
> vm_maps have a "feature" where they can mark that they're being
> operated on by a specific proc, and then release the rwlock protecting
> their state. to relock, you have to be the same proc that marked
> it busy.
>
> this diff tries to simplify it a bit. it basically has threads check
> the busy field up front and rechecks the busy field inside the
> rwlock. if you can sleep, it will sleep up front for the busy field
> to become clear, rather than sleep on either the busy field or the
> rwlock. some code paths clear the busy field without holding the
> rwlock, so it doesn't make sense to me to be waiting for the busy
> field but sleeping somewhere else.
>
> ok claudio@ mpi@
This caused by amd64 regress machine to panic. It goes straight to
reboot, no chance of capturing any output from ddb.
Here's a reproducer which compiles some Go application:
$ make -C $BSDSRC/regress/lib/libcrypto/c2sp
My amd64 desktop machine also locks up while starting firefox.
