Message ID | 20221018022701.683489-1-yebin10@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp1741367wrs; Mon, 17 Oct 2022 19:28:59 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7GrN81i29GqY6/mKkEHJiDMeVbjjPjQZ0ODOOjaU3RuGU8+txw87olqx3TcIVT8kBTVmy2 X-Received: by 2002:a05:6402:270b:b0:45d:61cd:73cc with SMTP id y11-20020a056402270b00b0045d61cd73ccmr582857edd.136.1666060139846; Mon, 17 Oct 2022 19:28:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666060139; cv=none; d=google.com; s=arc-20160816; b=OYkMWzBDI/oFqiAf16FHGwWojynZbNom2tH+mnLjfXvZIi2fLPiJjbKt/aPJh/R6Tm gdYTmClAErwXmC3MpkQnu8g9Gi4x9YYJ2txr6tZZtt8pFv3RlJWEgA1c2G8fiSqL5xdP 9iIg5yCn1LNnO7RXzB4b3K1Q922NbswOB3WDMtVDJESqwrUSkKhPIkvxQCUbgU1njSmo faKNecx0iIAlvxQUjtAgTjGwAidVMNfOv2VW4zIdSOdoW/f6xyzryAwkputdbIUSoEb1 GAsyHzfx3uD540fF7J6l3FYNx5NJYfjhGBNGhCCj0vYZ/AC8NcEv/n8OjF5dUHJoEytC 2tng== 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 :message-id:date:subject:cc:to:from; bh=AtSZ0XfWE272p74wRK+C5bvt3EVk9cDuRjPtIUj4hiA=; b=p6AQx2LQdPJzlYFEfAm3RSS6DBey/n5kragxUtC25VQkpWU7nF0Bo/5NT+pbWEkzR/ 45EmTxUpIYQDRqyFrXJjyWlVdoKk9pWDVyoF344dJuYpCbgPw+bQVkPdVCjEEZZjoo5Z BRy0Cx4WfbZnRpwC2SfYAPk2dDg/gbXozImmUEWonozVe8FTobB3E3hfVVc686mRZiXE sjnsygjdpXilpTo2FRTnArB3MrdU62h/zc2vd2Y41U3gqXPlHvNX84Q0V/MFFjmIOovo C9UZcasj03vtuSDkL+0En69/x2oDWrwYbvC8Z4Xki4nSgGowDychhdBabw4RT6icsB3h tQqg== 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 10-20020a508e0a000000b0045d0660a039si9503271edw.316.2022.10.17.19.28.35; Mon, 17 Oct 2022 19:28:59 -0700 (PDT) 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230271AbiJRCUw (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Mon, 17 Oct 2022 22:20:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230165AbiJRCUo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 17 Oct 2022 22:20:44 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4112D7E026; Mon, 17 Oct 2022 19:20:37 -0700 (PDT) Received: from canpemm500010.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Mrxs22v4XzVhwZ; Tue, 18 Oct 2022 10:00:22 +0800 (CST) Received: from huawei.com (10.175.127.227) by canpemm500010.china.huawei.com (7.192.105.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 18 Oct 2022 10:04:57 +0800 From: Ye Bin <yebin10@huawei.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+c740bb18df70ad00952e@syzkaller.appspotmail.com> Subject: [PATCH -next v2] ext4: fix warning in 'ext4_da_release_space' Date: Tue, 18 Oct 2022 10:27:01 +0800 Message-ID: <20221018022701.683489-1-yebin10@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To canpemm500010.china.huawei.com (7.192.105.118) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, 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?1746985400504799451?= X-GMAIL-MSGID: =?utf-8?q?1746990676980078862?= |
Series |
[-next,v2] ext4: fix warning in 'ext4_da_release_space'
|
|
Commit Message
Ye Bin
Oct. 18, 2022, 2:27 a.m. UTC
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461
mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589
ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852
do_writepages+0x3c3/0x680 mm/page-writeback.c:2469
__writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587
writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870
wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044
wb_do_writeback fs/fs-writeback.c:2187 [inline]
wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227
process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
Above issue may happens as follows:
ext4_da_write_begin
ext4_create_inline_data
ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);
ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);
__ext4_ioctl
ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag
ext4_da_write_begin
ext4_da_convert_inline_data_to_extent
ext4_da_write_inline_data_begin
ext4_da_map_blocks
ext4_insert_delayed_block
if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk))
if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk))
ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1
allocated = true;
ext4_es_insert_delayed_block(inode, lblk, allocated);
ext4_writepages
mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC
mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1
ext4_es_remove_extent
ext4_da_release_space(inode, reserved);
if (unlikely(to_free > ei->i_reserved_data_blocks))
-> to_free == 1 but ei->i_reserved_data_blocks == 0
-> then trigger warning as above
To solve above issue, forbid inode do migrate which has inline data.
Reported-by: syzbot+c740bb18df70ad00952e@syzkaller.appspotmail.com
Signed-off-by: Ye Bin <yebin10@huawei.com>
---
fs/ext4/migrate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On Tue 18-10-22 10:27:01, Ye Bin wrote: > Syzkaller report issue as follows: > EXT4-fs (loop0): Free/Dirty block details > EXT4-fs (loop0): free_blocks=0 > EXT4-fs (loop0): dirty_blocks=0 > EXT4-fs (loop0): Block reservation details > EXT4-fs (loop0): i_reserved_data_blocks=0 > EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524 > Modules linked in: > CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 > Workqueue: writeback wb_workfn (flush-7:0) > RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528 > RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 > RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 > RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 > RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 > R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 > R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 > FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 > mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 > ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 > do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 > __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 > writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 > wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 > wb_do_writeback fs/fs-writeback.c:2187 [inline] > wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 > process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 > worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 > kthread+0x266/0x300 kernel/kthread.c:376 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 > </TASK> > > Above issue may happens as follows: > ext4_da_write_begin > ext4_create_inline_data > ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS); > ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); > __ext4_ioctl > ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag > ext4_da_write_begin > ext4_da_convert_inline_data_to_extent > ext4_da_write_inline_data_begin > ext4_da_map_blocks > ext4_insert_delayed_block > if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) > if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk)) > ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1 > allocated = true; > ext4_es_insert_delayed_block(inode, lblk, allocated); > ext4_writepages > mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC > mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1 > ext4_es_remove_extent > ext4_da_release_space(inode, reserved); > if (unlikely(to_free > ei->i_reserved_data_blocks)) > -> to_free == 1 but ei->i_reserved_data_blocks == 0 > -> then trigger warning as above > > To solve above issue, forbid inode do migrate which has inline data. > > Reported-by: syzbot+c740bb18df70ad00952e@syzkaller.appspotmail.com > Signed-off-by: Ye Bin <yebin10@huawei.com> Yeah, makes sense. Feel free to add: Reviewed-by: Jan Kara <jack@suse.cz> Honza > --- > fs/ext4/migrate.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c > index 0a220ec9862d..a19a9661646e 100644 > --- a/fs/ext4/migrate.c > +++ b/fs/ext4/migrate.c > @@ -424,7 +424,8 @@ int ext4_ext_migrate(struct inode *inode) > * already is extent-based, error out. > */ > if (!ext4_has_feature_extents(inode->i_sb) || > - (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) > + ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS) || > + ext4_has_inline_data(inode)) > return -EINVAL; > > if (S_ISLNK(inode->i_mode) && inode->i_blocks == 0) > -- > 2.31.1 >
On Tue, 18 Oct 2022 10:27:01 +0800, Ye Bin wrote: > Syzkaller report issue as follows: > EXT4-fs (loop0): Free/Dirty block details > EXT4-fs (loop0): free_blocks=0 > EXT4-fs (loop0): dirty_blocks=0 > EXT4-fs (loop0): Block reservation details > EXT4-fs (loop0): i_reserved_data_blocks=0 > EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524 > Modules linked in: > CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 > Workqueue: writeback wb_workfn (flush-7:0) > RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528 > RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 > RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 > RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 > RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 > R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 > R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 > FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 > mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 > ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 > do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 > __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 > writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 > wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 > wb_do_writeback fs/fs-writeback.c:2187 [inline] > wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 > process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 > worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 > kthread+0x266/0x300 kernel/kthread.c:376 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 > </TASK> > > [...] Applied, thanks! [1/1] ext4: fix warning in 'ext4_da_release_space' commit: 1b8f787ef547230a3249bcf897221ef0cc78481b Best regards,
diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c index 0a220ec9862d..a19a9661646e 100644 --- a/fs/ext4/migrate.c +++ b/fs/ext4/migrate.c @@ -424,7 +424,8 @@ int ext4_ext_migrate(struct inode *inode) * already is extent-based, error out. */ if (!ext4_has_feature_extents(inode->i_sb) || - (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))) + ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS) || + ext4_has_inline_data(inode)) return -EINVAL; if (S_ISLNK(inode->i_mode) && inode->i_blocks == 0)