Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Don't lock rt_lock in range_tree_verify()
range_tree_verify() was the only range tree support function which locked rt_lock whereas all the other functions required the lock to be taken by the caller. If the lock is taken in range_tree_verify(), it's not possible to atomically verify a set of related range trees (those which are likely protected by the same lock). In the previous implementation, checking "related" trees would be done as follows: range_tree_verify(tree1, offset, size); /* tree1's rt_lock is not taken here */ range_tree_verify(tree2, offset, size); The new implementation requires: mutex_enter(tree1->rt_lock); range_tree_verify(tree1, offset, size); range_tree_verify(tree2, offset, size); mutex_exit(tree1->rt_lock); Currently, the only consumer of range_tree_verify() is metaslab_check_free() which verifies a set of realted range trees in a metaslab. The TRIM/DISCARD code adds an additional set of checks of the current and previous trimsets, both of which are represented as range trees. metaslab_check_free() has been updated to lock ms_lock once for each vdev's metaslab and also for debugging builds to verify that the each tree's rt_lock matches the metaslab's ms_lock to prove they're related.
- Loading branch information