On Tue, 17 Dec 2019, Mark Kettenis wrote: ... > > However, thos "vmmaplk" instances really are different classes. In > > the sys_mlock codepath it is a lock for a userland vmmap whereas the > > other codepath is dealing with a kernel vmmap. So there isn't > > actually a lock order reversal. > > > > Maybe it'd help if we used a separate rw_init() call for the lock of > > the kernel map? > > Something like this:
I like the direction. My one hesitation is that I seem to recall there being some handwaving about whether the vmmap's used by vmm are in vmspaces or not. Has this been tested with vmm's? Philip > Index: uvm/uvm_map.c > =================================================================== > RCS file: /cvs/src/sys/uvm/uvm_map.c,v > retrieving revision 1.259 > diff -u -p -r1.259 uvm_map.c > --- uvm/uvm_map.c 12 Dec 2019 11:12:36 -0000 1.259 > +++ uvm/uvm_map.c 17 Dec 2019 16:58:31 -0000 > @@ -2654,7 +2654,10 @@ uvm_map_setup(struct vm_map *map, vaddr_ > map->s_start = map->s_end = 0; /* Empty stack area by default. */ > map->flags = flags; > map->timestamp = 0; > - rw_init_flags(&map->lock, "vmmaplk", RWL_DUPOK); > + if (flags & VM_MAP_ISVMSPACE) > + rw_init_flags(&map->lock, "vmmaplk", RWL_DUPOK); > + else > + rw_init(&map->lock, "kmmaplk"); > mtx_init(&map->mtx, IPL_VM); > mtx_init(&map->flags_lock, IPL_VM); > > >
