ttm_backup_backup_folio(9)

📦 version 7.3.1, in nixpkgs unstable

💖 ttm_backup_backup_folio — it's giving "backup a folio" ✨

okay so bestie, welcome to the Kernel API Manual page for ttm_backup_backup_folio(9) and honestly? this one is a little crunchy but we're gonna get through it together 🫶 like it's from ./drivers/gpu/drm/ttm and it's literally the function that backs up a folio. the whole name.

It returns an s64, it lives in the kernel, and it has opinions about context. let's go 💅

🌸 SYNOPSIS 🌸

s64 ttm_backup_backup_folio (struct file *backup , struct folio *folio ,
unsigned int order , bool writeback , pgoff_t idx , gfp_t folio_gfp ,
gfp_t alloc_gfp , pgoff_t *nr_pages_backed );

eight arguments. EIGHT. not me counting on both hands 😭 but it's fine, they all make sense, i promise.

🎀 ARGUMENTS 🎀

  • backup — the struct backup pointer to use. your main character struct, fr fr.
  • folio — the folio to back up. the whole point of the function, no cap 🦋
  • order — the allocation order of folio. and okay this bit is highkey important: since TTM allocates higher-order pages without __GFP_COMP, folio_nr_pages(folio) would always return 1 😳 so the caller has to pass the true order explicitly. no shortcuts, bestie.
  • writeback — whether to perform immediate writeback of the folio's pages. lowkey it may have performance implications, so like… be aware 👀
  • idx — a unique integer for the first page of the folio and each struct backup. this lets the backup implementation avoid managing its address space separately, which is iconic of it actually 🎀
  • folio_gfp — the gfp value used when the folio was allocated. currently unused. so like, it's there, it's vibing, it's doing nothing 🙈
  • alloc_gfp — the gfp to be used when allocating memory.
  • nr_pages_backed — output 👑 on a successful return, it's set to the number of pages actually backed up. and heads up: that number may be less than (1 << order) if an -ENOMEM was encountered mid-folio. yes, partway through. it happens 💀

✨ CONTEXT ✨

okay this is the part where you read carefully, bestie, because it's giving "consequences" 🌈

If you're calling from reclaim context, the caller needs to assert that the shrinker gfp has __GFP_FS set — this is to avoid deadlocking on lock_page. deadlocking! we're not doing that today 🔥

And if writeback is set to true and you're called from reclaim context, the caller also needs to assert that the shrinker gfp has __GFP_IO set, since without it we're not allowed to start backup IO. like, the kernel said no 💅

⚠️ for real though: both of those assertions are on you, the caller. skip them and you get deadlocks or illegal IO, and nobody wants that energy.

💜 RETURN 💜

  • 🫶 A handle for the first backed-up page on success — and handles for subsequent pages follow sequentially, so it's a little conga line of handles.
  • 💀 -ENOMEM if no pages could be backed up.
  • 😭 Any other negative error code if a non-ENOMEM failure occurred — and in that case, any pages backed up so far are truncated before returning. cleanup crew said periodt.

🧚 SEE ALSO 🧚

Kernel file ./drivers/gpu/drm/ttm/ttm_backup.c, plus the rest of the backup fam:

and that's the page, bestie!! 🎀 go back up those folios responsibly 💖

mwah 💋 — this one's from ./drivers/gpu/drm/ttm, dated October 2026. slay, bye 👑

📦 where this page comes from