read_cache_page_gfp(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… read_cache_page_gfp β€” kernel API manual, but make it make sense πŸ’…

okay so bestie, you're reading the page for read_cache_page_gfp, and honestly? it's giving "small function, big responsibilities." let's get into it 🫢


✨ SYNOPSIS ✨

struct page * read_cache_page_gfp (struct address_space *mapping ,
pgoff_t index , gfp_t gfp );

three args, one struct page * coming back at you. no cap. 🌸


πŸŽ€ ARGUMENTS πŸŽ€

  • mapping β€” the page's address_space. like, which address space are we even doing this in, bestie? this one.
  • index β€” the page index. yes, the index. go find your page. πŸ”
  • gfp β€” the page allocator flags to use if allocating. these are your flags, you picked them, you own them. πŸ’…

πŸ’– DESCRIPTION πŸ’–

so this is literally the same as "read_mapping_page(mapping, index, NULL)", except any new page allocations get done using the allocation flags you specify. same vibe, your flags. ✨

if the page does not get brought uptodate, it returns -EIO. not great, not terrible, but definitely not the slay outcome. 😭

also β€” important, bestie β€” the function expects mapping->invalidate_lock to be already held when you call it. like, it's not gonna grab it for you. you gotta walk in with it. πŸ™ˆ

fr fr, hold the lock before you call this. the function is not doing the lock chores for you, that's not its job.

πŸ¦‹ RETURN πŸ¦‹

  • up to date page on success β€” iconic, we love a win πŸ‘‘
  • ERR_PTR on failure β€” not the moment, but okay πŸ’€

πŸ”₯ SEE ALSO πŸ”₯

Kernel file ./mm/filemap.c

like, that's a whole friend group. mwah. 🧚


and that's the page, bestie πŸ’œ this one came out of ./mm and it's dated October 2026 β€” so go forth, pass your gfp flags, hold your invalidate_lock, and slay. 🌈⭐

πŸ“¦ where this page comes from