[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e39845b3-e9b4-6ad3-4c53-402628471bcc@huawei.com>
Date: Sat, 9 Dec 2023 18:05:15 +0800
From: Baokun Li <libaokun1@...wei.com>
To: xingwei lee <xrivendell7@...il.com>, <harperchen1110@...il.com>
CC: <adilger.kernel@...ger.ca>, <linux-ext4@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <syzkaller-bugs@...glegroups.com>,
<syzkaller@...glegroups.com>, <tytso@....edu>,
Baokun Li <libaokun1@...wei.com>,
yangerkun <yangerkun@...wei.com>
Subject: Re: divide error in mb_update_avg_fragment_size
On 2023/12/8 22:12, xingwei lee wrote:
> Hello I saw you can't reproduce this bug and I reproduce it with
> repro.c and repro.txt
> I test the repro.c in the lastest HEAD: 5e3f5b81de80c98338bcb47c233aebefee5a4801
> kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=6ae1a4ee971a7305
> and the bug also existed.
Hello xingwei!
Thanks for the reproducer!
The problem is that the same range of physical blocks are freed in
ext4_mb_release_inode_pa() and ext4_process_freed_data() successively.
Thus in mb_free_blocks() bb_free is added twice, while bb_fragments
is added only once, the second time exiting early due to checking
for release of already freed blocks. So when fstrim marks all the
blocks in the group as already used, bb_free not being 0 and
bb_fragments being 0 triggers a divide-by-zero problem in
mb_update_avg_fragment_size().
We should avoid freeing blocks in ext4_mb_release_inode_pa() that
are about to be freed in ext4_process_freed_data(). I will send out
a patch after doing some tests.
Cheers!
--
With Best Regards,
Baokun Li
.
Powered by blists - more mailing lists