From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 2/3] btrfs: fix warning when freeing leaf after subvolume creation failure
Date: Mon, 13 Dec 2021 08:45:13 +0000 [thread overview]
Message-ID: <c6665f65ee7f7effc5665cde82a3f76461d566f9.1639384875.git.fdmanana@suse.com> (raw)
In-Reply-To: <cover.1639384875.git.fdmanana@suse.com>
From: Filipe Manana <fdmanana@suse.com>
When creating a subvolume, at ioctl.c:create_subvol(), if we fail to
insert the root item for the new subvolume into the root tree, we can
trigger the following warning:
[78961.741046] WARNING: CPU: 0 PID: 4079814 at fs/btrfs/extent-tree.c:3357 btrfs_free_tree_block+0x2af/0x310 [btrfs]
[78961.743344] Modules linked in:
[78961.749440] dm_snapshot dm_thin_pool (...)
[78961.773648] CPU: 0 PID: 4079814 Comm: fsstress Not tainted 5.16.0-rc4-btrfs-next-108 #1
[78961.775198] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[78961.777266] RIP: 0010:btrfs_free_tree_block+0x2af/0x310 [btrfs]
[78961.778398] Code: 17 00 48 85 (...)
[78961.781067] RSP: 0018:ffffaa4001657b28 EFLAGS: 00010202
[78961.781877] RAX: 0000000000000213 RBX: ffff897f8a796910 RCX: 0000000000000000
[78961.782780] RDX: 0000000000000000 RSI: 0000000011004000 RDI: 00000000ffffffff
[78961.783764] RBP: ffff8981f490e800 R08: 0000000000000001 R09: 0000000000000000
[78961.784740] R10: 0000000000000000 R11: 0000000000000001 R12: ffff897fc963fcc8
[78961.785665] R13: 0000000000000001 R14: ffff898063548000 R15: ffff898063548000
[78961.786620] FS: 00007f31283c6b80(0000) GS:ffff8982ace00000(0000) knlGS:0000000000000000
[78961.787717] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[78961.788598] CR2: 00007f31285c3000 CR3: 000000023fcc8003 CR4: 0000000000370ef0
[78961.789568] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[78961.790585] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[78961.791684] Call Trace:
[78961.792082] <TASK>
[78961.792359] create_subvol+0x5d1/0x9a0 [btrfs]
[78961.793054] btrfs_mksubvol+0x447/0x4c0 [btrfs]
[78961.794009] ? preempt_count_add+0x49/0xa0
[78961.794705] __btrfs_ioctl_snap_create+0x123/0x190 [btrfs]
[78961.795712] ? _copy_from_user+0x66/0xa0
[78961.796382] btrfs_ioctl_snap_create_v2+0xbb/0x140 [btrfs]
[78961.797392] btrfs_ioctl+0xd1e/0x35c0 [btrfs]
[78961.798172] ? __slab_free+0x10a/0x360
[78961.798820] ? rcu_read_lock_sched_held+0x12/0x60
[78961.799664] ? lock_release+0x223/0x4a0
[78961.800321] ? lock_acquired+0x19f/0x420
[78961.800992] ? rcu_read_lock_sched_held+0x12/0x60
[78961.801796] ? trace_hardirqs_on+0x1b/0xe0
[78961.802495] ? _raw_spin_unlock_irqrestore+0x3e/0x60
[78961.803358] ? kmem_cache_free+0x321/0x3c0
[78961.804071] ? __x64_sys_ioctl+0x83/0xb0
[78961.804711] __x64_sys_ioctl+0x83/0xb0
[78961.805348] do_syscall_64+0x3b/0xc0
[78961.805969] entry_SYSCALL_64_after_hwframe+0x44/0xae
[78961.806830] RIP: 0033:0x7f31284bc957
[78961.807517] Code: 3c 1c 48 f7 d8 (...)
This is because we are calling btrfs_free_tree_block() on an extent
buffer that is dirty. Fix that by cleaning the extent buffer, with
btrfs_clean_tree_block(), before freeing it.
This was triggered by test case generic/475 from fstests.
Fixes: 67addf29004c5b ("btrfs: fix metadata extent leak after failure to create subvolume")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
fs/btrfs/ioctl.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 1a6784e99082..7565b667f4fc 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -644,10 +644,11 @@ static noinline int create_subvol(struct user_namespace *mnt_userns,
* tree block so that we don't leak space and leave the
* filesystem in an inconsistent state (an extent item in the
* extent tree with a backreference for a root that does not
- * exists). Also no need to have the tree block locked since it
- * is not in any tree at this point, so no other task can find
- * it and use it.
+ * exists).
*/
+ btrfs_tree_lock(leaf);
+ btrfs_clean_tree_block(leaf);
+ btrfs_tree_unlock(leaf);
btrfs_free_tree_block(trans, objectid, leaf, 0, 1);
free_extent_buffer(leaf);
goto fail;
--
2.33.0
next prev parent reply other threads:[~2021-12-13 8:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 8:45 [PATCH 0/3] btrfs: fixes for an error path when creating a subvolume fdmanana
2021-12-13 8:45 ` [PATCH 1/3] btrfs: fix invalid delayed ref after subvolume creation failure fdmanana
2021-12-13 8:45 ` fdmanana [this message]
2021-12-13 8:45 ` [PATCH 3/3] btrfs: skip transaction commit after failure to create subvolume fdmanana
2021-12-13 11:22 ` [PATCH 0/3] btrfs: fixes for an error path when creating a subvolume Nikolay Borisov
2021-12-14 14:39 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c6665f65ee7f7effc5665cde82a3f76461d566f9.1639384875.git.fdmanana@suse.com \
--to=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).