drm_mm_scan_remove_block(9)

📦 version 7.3.1, in nixpkgs unstable

💅 drm_mm_scan_remove_block(9) — a Kernel API Manual moment

okay bestie, welcome to the Kernel API Manual page for drm_mm_scan_remove_block and honestly? she's a lil diva with rules. let's get into it ✨

🌸 NAME 🌸

drm_mm_scan_remove_block — remove a node from the scan list 🎀

🦋 SYNOPSIS 🦋

bool drm_mm_scan_remove_block (struct drm_mm_scan *scan , struct
drm_mm_node *node );

yes she returns a bool, yes she takes two structs, no we are not scared 💜

✨ ARGUMENTS ✨

  • scan — the active drm_mm scanner, aka the main character doing the scanning 👑
  • node — the drm_mm_node you're removing, bye babe 🫶

🔥 DESCRIPTION 🔥

okay so this is the part where you HAVE to listen, fr fr. Nodes must be removed in exactly the reverse order from the scan list as they have been added — like, for example, using list_add as they're added and then list_for_each over that eviction list to remove them. If you don't do it in that reverse order? the internal state of the memory manager will be corrupted. not cute at all, no cap 💀 so please respect the stack energy, it's giving LIFO and that is the vibe.

when the scan list is empty, the selected memory nodes can be freed 🎉 and here's the slay: an immediately following drm_mm_insert_node_in_range_generic, or one of the simpler versions of that function with !DRM_MM_SEARCH_BEST, will then return the just freed block — because it's sitting right at the top of the free_stack list. iconic behavior honestly 🌈

⚠️ reminder: reverse order only. corrupting the memory manager's internal state is not a personality trait, bestie 😭

⭐ RETURN ⭐

True if this block should be evicted, false otherwise. and when no hole has been found? it will always return false. no hole, no eviction, no drama 🙈

🎀 SEE ALSO 🎀

go read them all, iykyk 💖

and that's the whole page, bestie 🧚 from ./drivers/gpu/drm, dated October 2026 — drm_mm_scan_remove_block(9), signing off 💅✨

📦 where this page comes from