> Date: Thu, 9 Sep 2021 15:17:25 +0200 > From: Patrick Wildt <patr...@blueri.se> > > Am Thu, Sep 09, 2021 at 12:55:13PM +0200 schrieb Mark Kettenis: > > > Date: Wed, 8 Sep 2021 10:45:53 +0200 > > > From: Martin Pieuchot <m...@openbsd.org> > > > > > > On 07/09/21(Tue) 14:19, Patrick Wildt wrote: > > > > Hi, > > > > > > > > I was playing around a little with the mutex code and found that on > > > > arm64 there some uninitialized mutexes out there. > > > > > > > > I think the arm64 specific one is comparatively easy to solve. We > > > > either initialize the mtx when we initialize the rest of the pmap, or > > > > we move it into the global definition of those. I opted for the former > > > > version. > > > > > > Is the kernel pmap mutex supposed to be used? On i386 it isn't so the > > > mutex's IPL is set to -1 and we added a KASSERT() in splraise() to spot > > > any mistake. > > > > Indeed. The kernel pmap is special: > > > > * It can never disappear. > > > > * Page table pages are pre-allocated and are never freed. > > > > * Mappings are (largely) unmanaged (by uvm). > > > > Therefore the per-pmap lock isn't used for the kernel map on most > > (all?) architectures. > > The one that 'crashed' was pmap_tramp. I only changed the kernel pmap > because it was like 5 lines above (or below) and seemed to be missing it > as well.
Ah, interesting. What I said above applies to pmap_tramp as well. Double so, as it doesn't have any managed mappings. I guess the crash happened in the pmap_enter() call from pmap_postinit()? Doing the initialization for pmap_tramp probably makes sense though, since the mutex will only be used in that one pmap_enter() call and adding another comparison in pmap_lock() and pmap_unlock() could slow us down.
