From: Martin Pieuchot Subject: Re: sparc64 vs uvm_purge() To: tech@openbsd.org Date: Thu, 27 Nov 2025 19:07:46 +0100 On 26/11/25(Wed) 12:32, Martin Pieuchot 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. Now with the corresponding assert removed, found the hard way by deraadt@. ok? Index: uvm/uvm_glue.c =================================================================== RCS file: /cvs/src/sys/uvm/uvm_glue.c,v diff -u -p -r1.94 uvm_glue.c --- uvm/uvm_glue.c 11 Sep 2025 15:28:40 -0000 1.94 +++ uvm/uvm_glue.c 27 Nov 2025 18:00:47 -0000 @@ -315,8 +315,6 @@ uvm_purge(void) struct proc *p = curproc; struct vmspace *vm = p->p_vmspace; - KERNEL_ASSERT_UNLOCKED(); - #ifdef __HAVE_PMAP_PURGE pmap_purge(p); #endif 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 27 Nov 2025 18:00:06 -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 } }