From cf6f34aa3ada0be8c5f90fe93f48a75fea082c51 Mon Sep 17 00:00:00 2001 From: Josef Bacik Date: Thu, 20 Aug 2020 11:46:07 -0400 Subject: btrfs: introduce BTRFS_NESTING_NEW_ROOT for adding new roots The way we add new roots is confusing from a locking perspective for lockdep. We generally have the rule that we lock things in order from highest level to lowest, but in the case of adding a new level to the tree we actually allocate a new block for the root, which makes the locking go in reverse. A similar issue exists for snapshotting, we cow the original root for the root of a new tree, however they're at the same level. Address this by using BTRFS_NESTING_NEW_ROOT for these operations. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba --- fs/btrfs/locking.h | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'fs/btrfs/locking.h') diff --git a/fs/btrfs/locking.h b/fs/btrfs/locking.h index a6b59808e046..3ea81ed3320b 100644 --- a/fs/btrfs/locking.h +++ b/fs/btrfs/locking.h @@ -61,6 +61,15 @@ enum btrfs_lock_nesting { */ BTRFS_NESTING_SPLIT, + /* + * When promoting a new block to a root we need to have a special + * subclass so we don't confuse lockdep, as it will appear that we are + * locking a higher level node before a lower level one. Copying also + * has this problem as it appears we're locking the same block again + * when we make a snapshot of an existing root. + */ + BTRFS_NESTING_NEW_ROOT, + /* * We are limited to MAX_LOCKDEP_SUBLCLASSES number of subclasses, so * add this in here and add a static_assert to keep us from going over -- cgit v1.2.3