aboutsummaryrefslogtreecommitdiffstats
path: root/fs/btrfs/dev-replace.c
diff options
context:
space:
mode:
authorQu Wenruo <[email protected]>2025-06-15 22:44:25 +0000
committerDavid Sterba <[email protected]>2025-07-21 22:06:19 +0000
commit2936a6ac8d976f3c4de6fb5fbc00c5905c0cfec7 (patch)
tree6587b46893ff379e3f48fb4bf8f8bb7037791240 /fs/btrfs/dev-replace.c
parentbtrfs: get rid of re-entering of btrfs_get_tree() (diff)
downloadkernel-2936a6ac8d976f3c4de6fb5fbc00c5905c0cfec7.tar.gz
kernel-2936a6ac8d976f3c4de6fb5fbc00c5905c0cfec7.zip
btrfs: add assertions to make super block creation more clear
When calling sget_fc(), there are 3 different situations: a) Critical error No super block created. b) A new super block is created The fc->s_fs_info is transferred to the super block, and fc->s_fs_info is reset to NULL. In this case sb->s_root should still be NULL, and needs to be properly initialized later by btrfs_fill_super(). c) An existing super block is returned The fc->s_fs_info is untouched, and anything related to that fs_info should be properly cleaned up. This is not obvious even with the extra comments at sget_fc(). Enhance the situation by: - Add comments for case b) and c) Especially for case c), the fs_info and fs_devices cleanup happens at different timing, thus needs extra explanation. - Move the comments closer to case b) and case c) Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
Diffstat (limited to 'fs/btrfs/dev-replace.c')
0 files changed, 0 insertions, 0 deletions