From: "Lorenz (xha)" Subject: Re: cpu_exit() diet To: tech@openbsd.org Date: Sun, 18 May 2025 09:37:11 +0200 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".