> Date: Tue, 17 Dec 2019 09:55:06 +0100 (CET)
> From: Mark Kettenis <[email protected]>
>
> > Date: Tue, 17 Dec 2019 09:25:49 +0100
> > From: Anton Lindqvist <[email protected]>
> >
> > On Tue, Dec 17, 2019 at 04:01:52PM +1100, Bradley Latus wrote:
> > > Unsure if this ever got through.
> >
> > Already reported[1] but not fixed.
> >
> > [1]
> > https://syzkaller.appspot.com/bug?id=3871fa3807e9588df440bc83440638d52811160e
> >
>
> Not sure there is anything to "fix".
>
> What's happening here is that we have a code path (sys_mlock) that
> first takes a "vmmaplk" first and then takes the "inode" lock. But
> we also have a code path that takes the "inode" lock first and then
> takes a "vmmaplk".
>
> 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:
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);
