fs/ext4/extents-test.c
Source file repositories/reference/linux-study-clean/fs/ext4/extents-test.c
File Facts
- System
- Linux kernel
- Corpus path
fs/ext4/extents-test.c- Extension
.c- Size
- 34736 bytes
- Lines
- 1070
- Domain
- Core OS
- Bucket
- VFS And Filesystem Core
- Inferred role
- Core OS: implementation source
- Status
- source implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
kunit/test.hkunit/static_stub.hlinux/fs_context.hlinux/gfp_types.hlinux/stddef.hext4.hext4_extents.h
Detected Declarations
struct kunit_ctxstruct kunit_ext_statestruct kunit_ext_data_statestruct kunit_ext_test_paramenum kunit_test_typesfunction ext_kill_sbfunction ext_init_fs_contextfunction ext_setfunction extents_kunit_exitfunction __ext4_ext_dirty_stubfunction ext4_ext_insert_extent_stubfunction ext4_ext_zeroout_stubfunction ext4_issue_zeroout_stubfunction extents_kunit_initfunction check_bufferfunction ext4_map_query_blocksfunction test_split_convertfunction ext_get_descfunction test_split_convert_param_initfunction test_convert_initialized_param_initfunction test_handle_unwritten_init
Annotated Snippet
struct kunit_ctx {
/*
* Ext4 inode which has only 1 unwrit extent
*/
struct ext4_inode_info *k_ei;
/*
* Represents the underlying data area (used for zeroout testing)
*/
char *k_data;
} k_ctx;
/*
* describes the state of an expected extent in extent tree.
*/
struct kunit_ext_state {
ext4_lblk_t ex_lblk;
ext4_lblk_t ex_len;
bool is_unwrit;
};
/*
* describes the state of the data area of a writ extent. Used for testing
* correctness of zeroout.
*/
struct kunit_ext_data_state {
char exp_char;
ext4_lblk_t off_blk;
ext4_lblk_t len_blk;
};
enum kunit_test_types {
TEST_SPLIT_CONVERT,
TEST_CREATE_BLOCKS,
};
struct kunit_ext_test_param {
/* description of test */
char *desc;
/* determines which function will be tested */
int type;
/* is extent unwrit at beginning of test */
bool is_unwrit_at_start;
/* flags to pass while splitting */
int split_flags;
/* map describing range to split */
struct ext4_map_blocks split_map;
/* disable zeroout */
bool disable_zeroout;
/* no of extents expected after split */
int nr_exp_ext;
/*
* expected state of extents after split. We will never split into more
* than 3 extents
*/
struct kunit_ext_state exp_ext_state[3];
/* Below fields used for zeroout tests */
bool is_zeroout_test;
/*
* no of expected data segments (zeroout tests). Example, if we expect
* data to be 4kb 0s, followed by 8kb non-zero, then nr_exp_data_segs==2
*/
int nr_exp_data_segs;
/*
* expected state of data area after zeroout.
*/
struct kunit_ext_data_state exp_data_state[3];
};
static void ext_kill_sb(struct super_block *sb)
{
generic_shutdown_super(sb);
}
static int ext_init_fs_context(struct fs_context *fc)
{
return 0;
}
static int ext_set(struct super_block *sb, struct fs_context *fc)
{
Annotation
- Immediate include surface: `kunit/test.h`, `kunit/static_stub.h`, `linux/fs_context.h`, `linux/gfp_types.h`, `linux/stddef.h`, `ext4.h`, `ext4_extents.h`.
- Detected declarations: `struct kunit_ctx`, `struct kunit_ext_state`, `struct kunit_ext_data_state`, `struct kunit_ext_test_param`, `enum kunit_test_types`, `function ext_kill_sb`, `function ext_init_fs_context`, `function ext_set`, `function extents_kunit_exit`, `function __ext4_ext_dirty_stub`.
- Atlas domain: Core OS / VFS And Filesystem Core.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.