hi Martin,

On Fri, May 16, 2025 at 04:31:23PM +0200, Martin Pieuchot wrote:
> Diff below moves pmap_deactivate() and sched_exit() outside of
> cpu_exit(). 
> 
> The order of operations change for i386 and mips64:
> 
>  - For i386 pmap_deactivate() was missing but since it's a no-op it's fine.
> 
>  - For mips64 pmap_deactivate() was called before restoring `p_addr'.  It's
>    also harmless because it only clears the curpmap pointer.
> 
> I tested this on arm64, amd64 and i386.  I'd appreciate tests on other
> architectures to ensure there's no mistake.
> 
> ok?
> 
> Index: kern/kern_exit.c
> ===================================================================
> RCS file: /cvs/src/sys/kern/kern_exit.c,v
> diff -u -p -r1.246 kern_exit.c
> --- kern/kern_exit.c	16 May 2025 13:40:30 -0000	1.246
> +++ kern/kern_exit.c	16 May 2025 14:13:41 -0000
> @@ -382,16 +382,21 @@ exit1(struct proc *p, int xexit, int xsi
>  	 */
>  
>  	/*
> -	 * Finally, call machine-dependent code to switch to a new
> -	 * context (possibly the idle context).  Once we are no longer
> -	 * using the dead process's vmspace and stack, exit2() will be
> -	 * called to schedule those resources to be released by the
> -	 * reaper thread.
> -	 *
> -	 * Note that cpu_exit() will end with a call equivalent to
> -	 * cpu_switch(), finishing our execution (pun intended).
> +	 * Finally, call machine-dependent code.
>  	 */
>  	cpu_exit(p);
> +
> +	/*
> +	 * Deactivate the exiting address space before the vmspace
> +	 * is freed.  Note that we will continue to run on this
> +	 * vmspace's context until the switch to idle in sched_exit().
> +	 *
> +	 * Once we are no longer using the dead process's vmspace and
> +	 * stack, exit2() will be called to schedule those resources
> +	 * to be released by the reaper thread.
> +	 */
> +	pmap_deactivate(p);
> +	sched_exit(p);
>  	panic("cpu_exit returned");

i think that you may want to change the panic message to
"sched_exit returned".