> 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?
