https://bugzilla.kernel.org/show_bug.cgi?id=202879 --- Comment #8 from Theodore Tso (tytso@xxxxxxx) --- Jungyeon, One of the things you can do which would be helpful when creating a minimal reproducer, is to fix some of the gratuitous corruptions in the file system image, so we can be 100% sure which file sysutem corruption is combining with your test syscall load to trigger the failure. For example, both of these super block corruptions which cause e2fsck to stop dead in its track because it views the superblock as being too compromised for automated machine assumptions to be safe are probably things we can clear and still have ext4-combined dump core: % e2fsck -fy /tmp/tmp.img e2fsck 1.45.0 (6-Mar-2019) Found invalid V2 journal superblock fields (from V1 journal). Clearing fields beyond the V1 journal superblock... Corruption found in superblock. (desc_size = 33667). E2fsck fixed up the first problem automatically, and the second I could fix up using debugfs: debugfs -w -R "ssv s_desc_size 64" /tmp/tmp.img I'm suspect that root cause is that the block allocation bitmap has a block which is also used by the journal as being free. And if that block gets reallocated so that a directory block (which, being metadata is accessed via a buffer head) overlaps with the journal block, I can imagine all sorts of hilarity enusing. I will attach a proposed patch which should detect this case, and block the reuse of a block belonging to the journal. Can you try applying this patch to your LKL ext4-combined program, and see if it traps the file system corruption early enough that core dump doesn't get triggered? -- You are receiving this mail because: You are watching the assignee of the bug.
