On Mon, Nov 14, 2022 at 11:21:33AM -0500, Waiman Long wrote: > > lockdep_set_subclass() should be translated into a call to > lockdep_init_map_type(): > > #define lockdep_set_subclass(lock, sub) \ > lockdep_init_map_type(&(lock)->dep_map, #lock, (lock)->dep_map.key, > sub,\ > (lock)->dep_map.wait_type_inner, \ > (lock)->dep_map.wait_type_outer, \ > (lock)->dep_map.lock_type) > > All memory access should be within the bound of the given "&ei->i_data_sem". > Also lockdep_init_map_type() is not in the stack trace. So it is not a > problem within this lockdep_init_map_type() function. So is it possible that > the given inode pointer is invalid? Well, the inode pointer would be coming from iget(). And since this is coming from ext4 mount operation, we would be getting a fresh inode that should be freshly allocated. So the possibilities which comes to mind is some kind of use-after-free (probbly in f2fs) that was smashing the inode itself, such that ei->i_data_sem was pointing off into la-la-land, or in the inode cache's internal data srtuctures. The reason why I would assume it would be in f2fs is I *assume* syzkaller would have pruned down the test case enough to remove the messing around with mounting the invalid f2fs file system. But the other mystery here is why didn't KASAN report the use-after-free (if that it is what it was) in the thousands of f2fs mount and unmount operations before it finally triggered? Anyway, I plan to ignore this Syzkaller unless report Syzkaller (or someone else) can come up with a more minimal/reliable reproducer. (I mean, we could open a bug, but with kind of reproducer, it would get prioritized P3 or P4 and ignored for years until it finally got closed in a buganizer bankruptcy, so I figured I would just skip a few steps. :-) Cheers, - Ted
