summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJosef Bacik <jbacik@fusionio.com>2013-07-05 17:05:38 -0400
committerChris Mason <chris.mason@fusionio.com>2013-09-01 07:57:20 -0400
commitb2aaaa3b8c2153ef17f0e22287acbf8ee31a7c82 (patch)
treea747a6023641d9acfc532374a09d41c2c369aeb7
parent59516f6017c589e7316418fda6128ba8f829a77f (diff)
downloadlinux-b2aaaa3b8c2153ef17f0e22287acbf8ee31a7c82.tar.bz2
Btrfs: set lockdep class before locking new extent buffer
We've been seeing spurious complaints out of lockdep because the lock class name changes. This is happening because when we drop a snapshot we will lock a block before we've read it in, which sets the lockdep class to whatever the default is. Then once we read the thing in we reset the lockdep class to what it is supposed to be, which blows lockdeps' mind. This patch should fix the problem, it appears to be the only place where we do this sort of thing. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
-rw-r--r--fs/btrfs/extent-tree.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 1204c8ef6f32..7e172c6dba68 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -7173,6 +7173,8 @@ static noinline int do_walk_down(struct btrfs_trans_handle *trans,
next = btrfs_find_create_tree_block(root, bytenr, blocksize);
if (!next)
return -ENOMEM;
+ btrfs_set_buffer_lockdep_class(root->root_key.objectid, next,
+ level - 1);
reada = 1;
}
btrfs_tree_lock(next);