https://bugzilla.kernel.org/show_bug.cgi?id=200931 --- Comment #4 from Theodore Tso (tytso@xxxxxxx) --- Side note: I understand that the fuzzing algorithm you are using creates increasingly complex poc.c programs and crafted file system images. The problem is that both have included increasing large amounts of clutter that make it much harder to root cause the failure. An interesting research idea: is there some way you could automate simplifying the poc.c file? I just kept on cutting down the program; and if the failure went away, I would add back that line(s). And if the failure remained, I would try removing the next line(s). Even a brute-force "try removing operation N; does it fail/succeed"; and just incremently trying to remove each operation, one at a time, to see if the failure goes a way or not, would save me a huge amount of time. A similar thing could be done for the image. For example, the corrupted resize inode (#7) in your last couple of images has always been a red herring, and it causes "e2fsck -fn poc.img" to abort. So the first thing I've done is to run 'debugfs -w -R "clri <7> poc.img' and see if the failure remains. So far, it always has. (And unless you are trying to call one of the online resize ioctls, it almost certainly will make no difference.) Incrementally removing corruptions by using "e2fsck -f poc.img" and then seeing whether or not the failure goes away or not would also be useful --- although that one is actually less of a bother for a human to do by hand. Slimming down the the poc.c does take a large amount of toil, and if you have some automation framework that could do that automatically, that would be a great time-saver for the kernel developer. (It's why I haven't had time to look at your bug reports; each one takes the better part of half a day to analyze, and I don't have that much free time.) -- You are receiving this mail because: You are watching the assignee of the bug.
