Hi Ted, On (24/11/12 10:29), Theodore Ts'o wrote: > > I've a following syzkaller report (no reproducer); the report is > > against 5.15, but the same call-chain seems possible in current > > upstream as well. So I suspect that maybe ext4_xattr_inode_create() > > should take nested inode_lock (I_MUTEX_XATTR) instead. Does the > > patch below make any sense? > > These syzkaller reports result from mounting a corrupted (fuzzed) file > system typically when an inode is used in multiple contexts (e.g., as > a directory and an EA inode, etc.) at the same time. I certainly see your point, and I don't argue. > I'd have to take a closer look to see if it makes sense, but in > general, very often whenever we try to fix one of these it ends up > triggering some other syzkaller failure. I see, the one-liner that I posted sort of looks like an addition to d1bc560e9a9c7 which landed in ext4 recently. > And, these sorts of things don't actually result in actual security > problems (at worst, a hang / denial of service attack), and the right > thing to do is to just run fsck on the !@#?!? file system before > mounting the thing. So in our particular case reboot is a bad scenario. Looking at reports from the fleet I see a bunch of hung-task reboots with ext4 frames, e.g. ext4_update_i_disksize()->down_write()->schedule() /* forever */, but I can't claim that this is the deadlock that syzkaller has reported, it very well might not be.
