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
 		}
 	}