[BUG] kernel BUG in ext4_mb_release_inode_pa

[BUG] kernel BUG in ext4_mb_release_inode_pa

[Guoyu Yin]

Hi,

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.

The call trace indicates that the crash happens when closing a file
via the close system call, with ext4_discard_preallocations invoking
ext4_mb_release_inode_pa. Preliminary analysis suggests this could be
caused by filesystem metadata corruption or unsynchronized concurrent
operations. I recommend reviewing the EXT4 preallocated block
management logic, especially in concurrent scenarios and metadata
consistency.

This can be reproduced on:

HEAD commit:

38fec10eb60d687e30c8c6b5420d86e8149f7557

report: https://pastebin.com/raw/DbusXrC3

console output : https://pastebin.com/raw/rjVjX2cb

kernel config : https://pastebin.com/raw/u0Efyj5P

C reproducer : https://pastebin.com/raw/iKzXm7Ut

Re: [BUG] kernel BUG in ext4_mb_release_inode_pa

[Theodore Ts'o]

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

Re: [BUG] kernel BUG in ext4_mb_release_inode_pa

[Guoyu Yin]

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@mit.edu> 于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