filemap_dirty_folio(9)

📦 version 7.3.1, in nixpkgs unstable

💅 filemap_dirty_folio(9)

okay bestie, welcome to the Kernel API Manual — today's main character is filemap_dirty_folio, and honestly? she's kind of a big deal 🎀

✨ NAME ✨

filemap_dirty_folio — mark a folio dirty for filesystems that don't use buffer_heads, no cap 💖

🌸 SYNOPSIS 🌸

bool filemap_dirty_folio (struct address_space *mapping , struct folio
*folio );

like, literally that's the whole signature, copy it exactly pls 🫶

🦋 ARGUMENTS 🦋

  • mapping — the address space this folio belongs to. it's her home, her address space, her territory 💅
  • folio — the folio that's getting marked as dirty. yes, that kind of dirty, it's a filesystem thing 😭

⭐ DESCRIPTION ⭐

so here's the tea ☕ — filesystems that do not use buffer heads should call this function from their dirty_folio address space operation. that's it, that's the assignment, slay.

it ignores the contents of folio_get_private, which is lowkey important: if your filesystem marks individual blocks as dirty, then your filesystem has to handle that itself. nobody's gonna do it for you, bestie — that's your own lore 🧚

this is also sometimes used by filesystems that do use buffer_heads, specifically when a single buffer is being dirtied: we want to set the folio dirty in that case, but not all the buffers. and the vibes here are very specific — this is a "bottom-up" dirtying, whereas block_dirty_folio is a "top-down" dirtying. two different energies, iykyk 🌈

⚠️ the caller must ensure this doesn't race with truncation. most will simply hold the folio lock, but e.g. zap_pte_range calls with the folio mapped and the pte lock held, which also locks out truncation. no racing, periodt. 🚨

🔥 SEE ALSO 🔥

kernel file ./mm/page-writeback.c and the whole friend group:

and that's the page, bestie 💜 it lives in ./mm, it's dated October 2026, and it goes by filemap_dirty_folio(9) — mwah, go mark some folios dirty responsibly 👑💅

📦 where this page comes from