| Message ID | 20200221131124.24105-1-nborisov@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] btrfs: Remove superflous lock acquisition in __del_reloc_root | expand |
On 2020/2/21 下午9:11, Nikolay Borisov wrote: > __del_reloc_root is called from: > > a) Transaction commit via: > btrfs_transaction_commit > commit_fs_roots > btrfs_update_reloc_root > __del_reloc_root > > b) From the relocation thread with the following call chains: > > relocate_block_group > merge_reloc_roots > insert_dirty_subvol > btrfs_update_reloc_root > __del_reloc_root > > c) merge_reloc_roots > free_reloc_roots > __del_reloc_roots > > (The above call chain can called from btrfs_recover_relocation as well > but for the purpose of this fix this is irrelevant). > > The commont data structure that needs protecting is > fs_info->reloc_ctl->reloc_list as reloc roots are anchored at this list. > Turns out it's no needed to hold the trans_lock in __del_reloc_root > since consistency is already guaranteed by call chain b) above holding > a transaction while calling insert_dirty_subvol, meaning we cannot have > a concurrent transaction commit. For call chain c) above a snapshot of > the fs_info->reloc_ctl->reloc_list is taken with reloc_mutex held and > free_reloc_roots is called on this local snapshot. > > Those invariants are sufficient to prevent racing calls to > __del_reloc_root alongside other users of the list, as such it's fine > to drop the lock acquisition. > > Signed-off-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: Qu Wenruo <wqu@suse.com> Thanks, Qu > --- > fs/btrfs/relocation.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c > index 8076c340749f..e5cb64409f7c 100644 > --- a/fs/btrfs/relocation.c > +++ b/fs/btrfs/relocation.c > @@ -1381,9 +1381,7 @@ static void __del_reloc_root(struct btrfs_root *root) > BUG_ON((struct btrfs_root *)node->data != root); > } > > - spin_lock(&fs_info->trans_lock); > list_del_init(&root->root_list); > - spin_unlock(&fs_info->trans_lock); > kfree(node); > } > >
On Fri, Feb 21, 2020 at 03:11:23PM +0200, Nikolay Borisov wrote: > __del_reloc_root is called from: > > a) Transaction commit via: > btrfs_transaction_commit > commit_fs_roots > btrfs_update_reloc_root > __del_reloc_root > > b) From the relocation thread with the following call chains: > > relocate_block_group > merge_reloc_roots > insert_dirty_subvol > btrfs_update_reloc_root > __del_reloc_root > > c) merge_reloc_roots > free_reloc_roots > __del_reloc_roots > > (The above call chain can called from btrfs_recover_relocation as well > but for the purpose of this fix this is irrelevant). > > The commont data structure that needs protecting is > fs_info->reloc_ctl->reloc_list as reloc roots are anchored at this list. > Turns out it's no needed to hold the trans_lock in __del_reloc_root > since consistency is already guaranteed by call chain b) above holding > a transaction while calling insert_dirty_subvol, meaning we cannot have > a concurrent transaction commit. For call chain c) above a snapshot of > the fs_info->reloc_ctl->reloc_list is taken with reloc_mutex held and > free_reloc_roots is called on this local snapshot. > > Those invariants are sufficient to prevent racing calls to > __del_reloc_root alongside other users of the list, as such it's fine > to drop the lock acquisition. > > Signed-off-by: Nikolay Borisov <nborisov@suse.com> > --- > fs/btrfs/relocation.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c > index 8076c340749f..e5cb64409f7c 100644 > --- a/fs/btrfs/relocation.c > +++ b/fs/btrfs/relocation.c > @@ -1381,9 +1381,7 @@ static void __del_reloc_root(struct btrfs_root *root) > BUG_ON((struct btrfs_root *)node->data != root); > } > > - spin_lock(&fs_info->trans_lock); > list_del_init(&root->root_list); > - spin_unlock(&fs_info->trans_lock); This has been obsoleted by patch f44deb7442edf42abee6 ("btrfs: hold a ref on the root->reloc_root"), I think the locks are still needed but you may want take a look.
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 8076c340749f..e5cb64409f7c 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -1381,9 +1381,7 @@ static void __del_reloc_root(struct btrfs_root *root) BUG_ON((struct btrfs_root *)node->data != root); } - spin_lock(&fs_info->trans_lock); list_del_init(&root->root_list); - spin_unlock(&fs_info->trans_lock); kfree(node); }
__del_reloc_root is called from: a) Transaction commit via: btrfs_transaction_commit commit_fs_roots btrfs_update_reloc_root __del_reloc_root b) From the relocation thread with the following call chains: relocate_block_group merge_reloc_roots insert_dirty_subvol btrfs_update_reloc_root __del_reloc_root c) merge_reloc_roots free_reloc_roots __del_reloc_roots (The above call chain can called from btrfs_recover_relocation as well but for the purpose of this fix this is irrelevant). The commont data structure that needs protecting is fs_info->reloc_ctl->reloc_list as reloc roots are anchored at this list. Turns out it's no needed to hold the trans_lock in __del_reloc_root since consistency is already guaranteed by call chain b) above holding a transaction while calling insert_dirty_subvol, meaning we cannot have a concurrent transaction commit. For call chain c) above a snapshot of the fs_info->reloc_ctl->reloc_list is taken with reloc_mutex held and free_reloc_roots is called on this local snapshot. Those invariants are sufficient to prevent racing calls to __del_reloc_root alongside other users of the list, as such it's fine to drop the lock acquisition. Signed-off-by: Nikolay Borisov <nborisov@suse.com> --- fs/btrfs/relocation.c | 2 -- 1 file changed, 2 deletions(-)