Don't clear the cpu's bit in the old pmap's pm_cpus until we're off
authorguenther <guenther@openbsd.org>
Tue, 1 Jun 2021 21:12:11 +0000 (21:12 +0000)
committerguenther <guenther@openbsd.org>
Tue, 1 Jun 2021 21:12:11 +0000 (21:12 +0000)
commit9f1181d59de355abd911a3e0ab234c28078875ed
treea134ca9fd949e84e067b784ca1746f027d89c3b3
parente3fbd32f2667047d2063fdcf52c1c20ea8db306d
Don't clear the cpu's bit in the old pmap's pm_cpus until we're off
the old one and set it in the new pmap's pm_cpus before loading
%cr3 with the new value.  In particular, do neither if %cr3 isn't
changing.

This eliminates a window where, when switching between threads in
a single a process, the pmap wouldn't have this cpu's bit set even
though we didn't change %cr3.  With more of uvm unlocked, it was
possible for another cpu to update the page tables but not see a
need to send an IPI to this cpu, leading to crashes when TLB entries
that should have been invalidated were used.

malloc_duel testing by abluhm@
ok abluhm@ kettenis@ mlarkin@
sys/arch/amd64/amd64/locore.S