On Tue, Dec 17, 2019 at 09:11:28AM -0800, guent...@openbsd.org wrote: > 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 >
not sure if it's been tested but we've moved to 'real' vmspaces now and not just 'bare' vm_maps. -ml > > 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); > > > > > > >
