diff options
| author | Qu Wenruo <[email protected]> | 2025-06-15 22:44:25 +0000 |
|---|---|---|
| committer | David Sterba <[email protected]> | 2025-07-21 22:06:19 +0000 |
| commit | 2936a6ac8d976f3c4de6fb5fbc00c5905c0cfec7 (patch) | |
| tree | 6587b46893ff379e3f48fb4bf8f8bb7037791240 /fs/btrfs/dev-replace.c | |
| parent | btrfs: get rid of re-entering of btrfs_get_tree() (diff) | |
| download | kernel-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
