Documentation/filesystems/mmap_prepare.rst
Source file repositories/reference/linux-study-clean/Documentation/filesystems/mmap_prepare.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/filesystems/mmap_prepare.rst- Extension
.rst- Size
- 6092 bytes
- Lines
- 169
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: operation-table or driver-model contract
- Status
- pattern implementation candidate
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct vm_area_descfunction ext4_file_mmap_prepare
Annotated Snippet
In your driver's struct file_operations struct, specify an ``mmap_prepare``
callback rather than an ``mmap`` one, e.g. for ext4:
.. code-block:: C
const struct file_operations ext4_file_operations = {
...
.mmap_prepare = ext4_file_mmap_prepare,
};
This has a signature of ``int (*mmap_prepare)(struct vm_area_desc *)``.
Examining the struct vm_area_desc type:
.. code-block:: C
struct vm_area_desc {
/* Immutable state. */
const struct mm_struct *const mm;
struct file *const file; /* May vary from vm_file in stacked callers. */
unsigned long start;
unsigned long end;
/* Mutable fields. Populated with initial state. */
pgoff_t pgoff;
struct file *vm_file;
vma_flags_t vma_flags;
pgprot_t page_prot;
/* Write-only fields. */
const struct vm_operations_struct *vm_ops;
void *private_data;
/* Take further action? */
struct mmap_action action;
};
This is straightforward - you have all the fields you need to set up the
mapping, and you can update the mutable and writable fields, for instance:
.. code-block:: C
static int ext4_file_mmap_prepare(struct vm_area_desc *desc)
{
int ret;
struct file *file = desc->file;
struct inode *inode = file->f_mapping->host;
...
file_accessed(file);
if (IS_DAX(file_inode(file))) {
desc->vm_ops = &ext4_dax_vm_ops;
vma_desc_set_flags(desc, VMA_HUGEPAGE_BIT);
} else {
desc->vm_ops = &ext4_file_vm_ops;
}
return 0;
}
Importantly, you no longer have to dance around with reference counts or locks
when updating these fields - **you can simply go ahead and change them**.
Everything is taken care of by the mapping code.
VMA Flags
---------
Along with ``mmap_prepare``, VMA flags have undergone an overhaul. Where before
you would invoke one of vm_flags_init(), vm_flags_reset(), vm_flags_set(),
Annotation
- Detected declarations: `struct vm_area_desc`, `function ext4_file_mmap_prepare`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: pattern 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.