Hi, Thank you for your response and suggestions.I have implemented the reproduction program based on your suggestions. With these changes, I have successfully reproduced the kernel BUG in ext4_mb_release_inode_pa, but the crash triggers after 5-8 runs on average, please try a few more times. The new C reproducer: https://pastebin.com/raw/jWYWQHPP Best regards, Guoyu Theodore Ts'o <tytso@xxxxxxx> 于2025年5月15日周四 22:16写道： > > On Thu, May 15, 2025 at 05:58:40PM +0800, Guoyu Yin wrote: > > > > I discovered a kernel crash described as "kernel BUG in > > ext4_mb_release_inode_pa." This issue occurs in the EXT4 filesystem's > > ext4_mb_release_inode_pa function (fs/ext4/mballoc.c:5339), where a > > BUG() assertion fails due to a mismatch between the calculated free > > block count free and the expected value pa->pa_free during > > preallocated block release. > > I can't reproduce the BUG using qemu,with the kernel config, kernel > commit, and C reproducer that you have provided. This is why I > strongly suggest that if people really feel the need to set up their > own syzkaller instances, perhaps because they are maing changes to > syzkaller, that they replicate the full syzkaler setup, including the > web dashboard and e-mail responder so that people can request that the > reproducer be run on your setup so we can figure out how easily > reproducible the report might be, and whether it has been fixed in a > more recent kernel version, or via a proposed bug fix. > > You are most likely correct that it is caused by a corrupted file > system, and this is why I strongly recommend that users run fsck -y on > any file system image of uncertain provenance before trying to mount > said file system. In addition, note that if the file system had been > mounted with errors=remount-ro, the problem wouldn't have resulted in > a BUG. For this reason, especially when the C reprducer doesn't > reproduce the reported issue, this sorts of issues are a very low > priority to investigate. > > Best regards, > > - Ted
