Martin Pieuchot <mpi@grenadille.net> wrote:

> sparc64 is subtly broken since uvm_purge() is running in parallel.  It
> became obvious that the architecture requires more MD work before more
> parts of UVM can run in parallel. 
> 
> That said, such breakages are not helping.  So here's a diff I sent
> before release to not run uvm_purge() w/o KERNEL_LOCK() on sparc64.
> I'd like to get it in.  Anyone interested in exposing pmap/UVM races
> on sparc64 will now where to start.
> 
> ok?
> 
> Index: kern/kern_exit.c
> ===================================================================
> RCS file: /cvs/src/sys/kern/kern_exit.c,v
> diff -u -p -r1.252 kern_exit.c
> --- kern/kern_exit.c	10 Aug 2025 15:17:57 -0000	1.252
> +++ kern/kern_exit.c	26 Nov 2025 11:19:21 -0000
> @@ -253,11 +253,13 @@ exit1(struct proc *p, int xexit, int xsi
>  			 * It is safe to release them all since exit1()
>  			 * will not return.
>  			 */
> -#ifdef MULTIPROCESSOR
> +#if defined(MULTIPROCESSOR) && !defined(__sparc64__)
>  			__mp_release_all(&kernel_lock);
>  #endif
>  			uvm_purge();
> +#if !defined(__sparc64__)
>  			KERNEL_LOCK();
> +#endif
>  		}
>  	}
>  

Not even close.


vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
bootpath: /pci@8000,0/pci@4,0/pci@0,0/pci@0,0/scsi@0,0/disk@5000cca0433dd981,0
root on sd0a (0c94b687783a1594.a) swap on sd0b dump on sd0b
panic: kernel diagnostic assertion "panicstr || db_active || !_kernel_lock_held
()" failed: file "/usr/src/sys/uvm/uvm_glue.c", line 318
Stopped at      db_enter+0x8:   nop
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
 115370  76484      0     0x14000      0x200   10K systq
__assert(17d3db8, 17e4f48, 13e, 17e4f80, 7ff, 1c00) at __assert+0x20
uvm_purge(4002567b590, 64, 0, 0, 0, 1c00) at uvm_purge+0x90
exit1(40025654860, 0, 0, 4000000, 17a4a60, 3) at exit1+0x654
sys_exit(40025654860, 401d10f9f40, 401d10f9e00, 193bc38, 17a4a60, 6) at sys_exi
t+0x10
syscall(401d10f9ee0, 1a0e110, 401d10f9f40, 1c00, 406d75ff140, 19df680) at sysca
ll+0x3c0
syscall_setup(0, 2000, 3a8383ff10, 10e8, 3a83840d40, 3a838382d8) at syscall_set
up+0x124
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.