[v2,1/3] ext4: fix incorrect calculate 'reserved' in '__es_remove_extent' when enable bigalloc feature
Message ID | 20221121121434.1061725-2-yebin@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1539734wrr; Mon, 21 Nov 2022 04:01:37 -0800 (PST) X-Google-Smtp-Source: AA0mqf7WXzRUeTysOl49G0+/yowrcNwRrWpwo23+zsCrydbsDp4TbTEzVbxxj9++d/kmEzkYyspw X-Received: by 2002:a17:906:6d7:b0:781:951:2fb with SMTP id v23-20020a17090606d700b00781095102fbmr15052754ejb.64.1669032096939; Mon, 21 Nov 2022 04:01:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669032096; cv=none; d=google.com; s=arc-20160816; b=RCb1eZybFnYqF5EqynnbaTV67uIQXQUJ4FAv+cBOii3N/i5sNqH6uU9wHeO+IjEMrW CXYek8nMUnZD+nv9GGsZws+a790zowhrndj7N3MNanpdbb9b8m9KA9N7e64b+Xv3en8B QECtZ0M1k3G+eRmCMxwAu6q6e70nOJHjVFS35ofcVLx6HuGndeS4NnMAmtz/awBx9jEz csr6u6UlOHns7nfEnK0nKQrBw7HXNjzFbJlYfY6k2sEBT9m5r+3feEXi7SrrBAV2FtM2 EPGTM62Bbnjd4tDUdvwBJbZJOtflCuWgAyxsQRVU1d4IIuD9qFaqemGjRVpnL4qfAnNi y/8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=z91nk14mIObIqOVp8zgISmF4ZiBR3Rao3nom0meyhAE=; b=kjwWXuyJC3vaGN5sSqdKB8GDh7eR3u9Hzq4RYbsZ/jJhxsClfh4ZUUVTpUTFEpcxDn 73qiZBEB/ek6euEEug1tG/kuCIxG3eod9v8VfD4pE9VCZKGhMYQ693J9b/vYeTcEJdco 1Xqjnym68iMhTWCHOpbykTO8ovOYkNLzrn9JJCrRBIsWniHdx5anKL0RnsujqIgzQrvP 6fTxPVDYuPtGqIeWpJtwsKcvlrdOJBA/FtfTWfdc3zyPBHzmHSnT18+nx5w564LBvwVE 4riNcmZjXOV/zZy10EwYBTkmnpZhDZxGe2Ym35upLkv9FPIaJBjcvqeDOdNIUEz4Bc85 BgDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x12-20020a170906148c00b00791a3dd01b6si8125123ejc.864.2022.11.21.04.00.58; Mon, 21 Nov 2022 04:01:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231232AbiKULxi (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Mon, 21 Nov 2022 06:53:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230124AbiKULxY (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 21 Nov 2022 06:53:24 -0500 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 905B9F39; Mon, 21 Nov 2022 03:53:22 -0800 (PST) Received: from mail02.huawei.com (unknown [172.30.67.153]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4NG5PS2tllz4f3jHx; Mon, 21 Nov 2022 19:53:16 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.127.227]) by APP4 (Coremail) with SMTP id gCh0CgDHONatZntj0uehAw--.51112S5; Mon, 21 Nov 2022 19:53:19 +0800 (CST) From: Ye Bin <yebin@huaweicloud.com> To: tytso@mit.edu, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org Cc: linux-kernel@vger.kernel.org, jack@suse.cz, Ye Bin <yebin10@huawei.com>, syzbot+05a0f0ccab4a25626e38@syzkaller.appspotmail.com Subject: [PATCH v2 1/3] ext4: fix incorrect calculate 'reserved' in '__es_remove_extent' when enable bigalloc feature Date: Mon, 21 Nov 2022 20:14:32 +0800 Message-Id: <20221121121434.1061725-2-yebin@huaweicloud.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20221121121434.1061725-1-yebin@huaweicloud.com> References: <20221121121434.1061725-1-yebin@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: gCh0CgDHONatZntj0uehAw--.51112S5 X-Coremail-Antispam: 1UD129KBjvJXoWxJF1UXr1rXF4UJF45CryrCrg_yoW8Kr48p3 y8Ar4UWryfuw1UW3yftw1j9Fn29a4UCrW7WFs3t343uFy5A34Sgr10yFs0vFWYqrWIqw4U XF4rKw1jq3WUXaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvCb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUGw A2048vs2IY020Ec7CjxVAFwI0_JFI_Gr1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxS w2x7M28EF7xvwVC0I7IYx2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxV W8Jr0_Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMc Ij6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_ Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr 0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY 17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcV C0I7IYx2IY6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY 6I8E87Iv67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsGvfC2Kf nxnUUI43ZEXa7IU1M7K7UUUUU== X-CM-SenderInfo: p1hex046kxt4xhlfz01xgou0bp/ X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750107000165838117?= X-GMAIL-MSGID: =?utf-8?q?1750107000165838117?= |
Series |
Fix two issues about bigalloc feature
|
|
Commit Message
Ye Bin
Nov. 21, 2022, 12:14 p.m. UTC
From: Ye Bin <yebin10@huawei.com> Syzbot report issue as follows: EXT4-fs error (device loop0): ext4_validate_block_bitmap:398: comm rep: bg 0: block 5: invalid block bitmap EXT4-fs (loop0): Delayed block allocation failed for inode 18 at logical offset 0 with max blocks 32 with error 28 EXT4-fs (loop0): This should not happen!! Data will be lost EXT4-fs (loop0): Total free blocks count 0 EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): free_blocks=0 EXT4-fs (loop0): dirty_blocks=32 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): i_reserved_data_blocks=2 EXT4-fs (loop0): Inode 18 (00000000845cd634): i_reserved_data_blocks (1) not cleared! Above issue happens as follows: Assume: sbi->s_cluster_ratio = 16 Step1: Insert delay block [0, 31] -> ei->i_reserved_data_blocks=2 Step2: ext4_writepages mpage_map_and_submit_extent -> return failed mpage_release_unused_pages -> to release [0, 30] ext4_es_remove_extent -> remove lblk=0 end=30 __es_remove_extent -> len1=0 len2=31-30=1 __es_remove_extent: ... if (len2 > 0) { ... if (len1 > 0) { ... } else { es->es_lblk = end + 1; es->es_len = len2; ... } if (count_reserved) count_rsvd(inode, lblk, orig_es.es_len - len1 - len2, &orig_es, &rc); goto out; -> will return but didn't calculate 'reserved' ... Step3: ext4_destroy_inode -> trigger "i_reserved_data_blocks (1) not cleared!" To solve above issue if 'len2>0' call 'get_rsvd()' before goto out. Reported-by: syzbot+05a0f0ccab4a25626e38@syzkaller.appspotmail.com Signed-off-by: Ye Bin <yebin10@huawei.com> --- fs/ext4/extents_status.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Comments
* Ye Bin <yebin@huaweicloud.com>: > From: Ye Bin <yebin10@huawei.com> > > Syzbot report issue as follows: > EXT4-fs error (device loop0): ext4_validate_block_bitmap:398: comm rep: bg 0: block 5: invalid block bitmap > EXT4-fs (loop0): Delayed block allocation failed for inode 18 at logical offset 0 with max blocks 32 with error 28 > EXT4-fs (loop0): This should not happen!! Data will be lost > > EXT4-fs (loop0): Total free blocks count 0 > EXT4-fs (loop0): Free/Dirty block details > EXT4-fs (loop0): free_blocks=0 > EXT4-fs (loop0): dirty_blocks=32 > EXT4-fs (loop0): Block reservation details > EXT4-fs (loop0): i_reserved_data_blocks=2 > EXT4-fs (loop0): Inode 18 (00000000845cd634): i_reserved_data_blocks (1) not cleared! > > Above issue happens as follows: > Assume: > sbi->s_cluster_ratio = 16 > Step1: Insert delay block [0, 31] -> ei->i_reserved_data_blocks=2 > Step2: > ext4_writepages > mpage_map_and_submit_extent -> return failed > mpage_release_unused_pages -> to release [0, 30] > ext4_es_remove_extent -> remove lblk=0 end=30 > __es_remove_extent -> len1=0 len2=31-30=1 > __es_remove_extent: > ... > if (len2 > 0) { > ... > if (len1 > 0) { > ... > } else { > es->es_lblk = end + 1; > es->es_len = len2; > ... > } > if (count_reserved) > count_rsvd(inode, lblk, orig_es.es_len - len1 - len2, &orig_es, &rc); > goto out; -> will return but didn't calculate 'reserved' > ... > Step3: ext4_destroy_inode -> trigger "i_reserved_data_blocks (1) not cleared!" > > To solve above issue if 'len2>0' call 'get_rsvd()' before goto out. > > Reported-by: syzbot+05a0f0ccab4a25626e38@syzkaller.appspotmail.com > Signed-off-by: Ye Bin <yebin10@huawei.com> > --- > fs/ext4/extents_status.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c > index cd0a861853e3..4684eaea9471 100644 > --- a/fs/ext4/extents_status.c > +++ b/fs/ext4/extents_status.c > @@ -1371,7 +1371,7 @@ static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk, > if (count_reserved) > count_rsvd(inode, lblk, orig_es.es_len - len1 - len2, > &orig_es, &rc); > - goto out; > + goto count; > } > > if (len1 > 0) { > @@ -1413,6 +1413,7 @@ static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk, > } > } > > +count: > if (count_reserved) > *reserved = get_rsvd(inode, end, es, &rc); > out: > -- > 2.31.1 > I'm unable to find the sysbot report for this patch, so I can't verify that this fix works. The more serious problem would be whatever is causing the invalid block bitmap and delayed allocation failure messages before the i_reserved_data_blocks message. Perhaps that's simply what syzkaller set up, but it's not clear from this posting. Have you looked for the cause of those first two messages? However, by inspection this patch should fix an obvious bug causing that last message, introduced by 8fcc3a580651 ("ext4: rework reserved cluster accounting when invalidating pages"). A Fixes tag should be added to the patch. Also, the readability of the code should be improved by changing the label "count" to the more descriptive "out_get_reserved". With those two changes, feel free to add: Reviewed-by: Eric Whitney <enwlinux@gmail.com> Eric
diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index cd0a861853e3..4684eaea9471 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -1371,7 +1371,7 @@ static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk, if (count_reserved) count_rsvd(inode, lblk, orig_es.es_len - len1 - len2, &orig_es, &rc); - goto out; + goto count; } if (len1 > 0) { @@ -1413,6 +1413,7 @@ static int __es_remove_extent(struct inode *inode, ext4_lblk_t lblk, } } +count: if (count_reserved) *reserved = get_rsvd(inode, end, es, &rc); out: