page_address_in_vma(9)
π page_address_in_vma β the Kernel API Manual (yep, that's the manual, we're in it)
okay so bestie, welcome to page_address_in_vma(9) β genuinely one of those little functions that does exactly what its name says, which, honestly? iconic behavior. no cap. β¨
πΈ NAME
page_address_in_vma β the virtual address of a page in this VMA. that's it, that's the whole vibe π
β¨ SYNOPSIS
unsigned long page_address_in_vma (const struct folio *folio , const
struct page *page , const struct vm_area_struct *vma );
like, look at it. three args, one unsigned long out. clean. minimal. main character energy. π
π«Ά ARGUMENTS
folioβ the folio containing the page. it's the big container energy, the friend group the page belongs to πpageβ the page within the folio. yes bestie, the actual page inside that folio. we love a nested situation πͺvmaβ the VMA we need to know the address in. that's the memory region we're asking about, fr fr πΊοΈ
π¦ DESCRIPTION
so what it actually does: it calculates the user virtual address of this page in the specified VMA. that's the whole thing. nailed it. β
but here's the part where you gotta listen, babes π¨ β it is the caller's responsibility to check that the page is actually within the VMA. this function is not doing that vibe check for you. you're on your own there, iykyk π
also: there may not currently be a PTE pointing at this page. like, right now, maybe nothing. but if a page fault occurs at this address, this is the page which will be accessed. so it's giving foreshadowing. it's giving "trust me, this is where it's gonna be." πβ¨
π CONTEXT
before you even think about calling this, two rules, and they're not optional:
- the caller should hold a reference to the folio π«Ά
- the caller should hold a lock (eg the
i_mmap_lockor themmap_lock) which keeps the VMA from being altered π‘οΈ
that second one matters. the VMA cannot be getting shuffled around under you while you're doing this. hold the lock. be a responsible little gremlin. π
π RETURN
the virtual address corresponding to this page in the VMA. an unsigned long. that's the gift. that's the whole payoff. take it and go π
π§ SEE ALSO
kernel file ./mm/rmap.c and honestly the whole extended friend group:
__anon_vma_prepare(9)anon_vma_clone(9)unlink_anon_vmas(9)folio_referenced(9)mapping_wrprotect_range(9)pfn_mkclean_range(9)folio_move_anon_rmap(9)__folio_set_anon(9)__page_check_anon_rmap(9)folio_add_anon_rmap_ptes(9)folio_add_anon_rmap_pmd(9)folio_add_new_anon_rmap(9)folio_add_file_rmap_ptes(9)folio_add_file_rmap_pmd(9)folio_add_file_rmap_pud(9)folio_remove_rmap_ptes(9)folio_remove_rmap_pmd(9)folio_remove_rmap_pud(9)try_to_unmap(9)try_to_migrate(9)make_device_exclusive(9)__rmap_walk_file(9)
that's the whole rmap squad right there. pt-es, pmd, pud, anon, file, add, remove, unmap, migrate β the full roster. obsessed. π
lowkey reminder: check the page is in the VMA yourself, and hold that folio reference + lock. this function trusts you. don't make it regret that. π
and that's the tea! β this little gem lives in ./mm, and this particular page is dated October 2026 β so like, see you in the future bestie, mwah ππβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms