get_hwpoison_page(9)

💅 get_hwpoison_page — the Kernel API Manual girlie edition

okay so bestie, welcome to get_hwpoison_page(9) — the function whose whole personality is "gimme a refcount on this busted page so we can deal with the memory error". come sit with me, this one's a bop 🫶

---

✨ NAME ✨

get_hwpoison_page — Get refcount for memory error handling 💖

---

🎀 SYNOPSIS 🎀

int get_hwpoison_page (struct page *p , unsigned long flags );

that's it. that's the whole mood. look at her go 🦋

---

🌸 ARGUMENTS 🌸

• p — the raw error page, aka the one that got hit by the memory error. this is our main character, our problem child, our literal blorbo 😭
• flags — flags that control the behavior of error handling. the vibes-configurator, if you will ✨

---

🧚 DESCRIPTION 🧚

so what does get_hwpoison_page actually do? it takes a page refcount of an error page so we can handle the memory error on it — but like, not before checking that the error page is in a well-defined state. and "well-defined state" here means a page-type we can actually successfully handle the memory error on, like an LRU page or a hugetlb page. no cap, that's the whole gatekeep 💅

here's the tea though: memory error handling can be triggered at any time on any type of page, so it's lowkey prone to racing with the typical memory management lifecycle (you know, allocation and free, the usual suspects). 🙈

so to avoid those races, get_hwpoison_page takes extra care for the error page's state (as done in __get_hwpoison_page), and has some retry logic in get_any_page. she's thorough. she's careful. she ate and left no crumbs 🔥

and one more thing, bestie — when called from unpoison_memory, the caller should already ensure that the given page has PG_hwpoison. which means it's never reused for other page allocations, and __get_unpoison_page never races with them. iconic behavior, honestly 👑

---

⭐ RETURN ⭐

the return values, ranked with love:

• 0 — on failure, or a free buddy (hugetlb) page 💀
• 1 — on success for in-use pages in a well-defined state 🎉
• -EIO — for pages on which we can not handle memory errors 🚫
• -EBUSY — when get_hwpoison_page has raced with page lifecycle operations like allocation and free 🏃‍♀️💨
• -EHWPOISON — when the page is hwpoisoned and taken off from buddy 😵
• -ENOTRECOVERABLE — for kernel-owned pages identified by is_kernel_owned_page (PG_reserved, slab, page-table, large-kmalloc) that the handler cannot recover. yeah. that's a no from her 🙅‍♀️

---

🔮 SEE ALSO 🔮

go read these next, bestie, they're all in the same friend group:

• Kernel file ./mm/memory-failure.c
• MF_ATTR_RO(9)
• mf_dax_kill_procs(9)
• memory_failure_pfn(9)
• memory_failure(9)
• memory_failure_queue(9)
• unpoison_memory(9)
• soft_offline_page(9)

---

fr fr, this page is dangerous-adjacent territory — it's out here racing with allocation and free, so keep those retry vibes and refcounts in mind. 🫧

alright bestie, that's the whole page — source is the ./mm directory, this is the Kernel API Manual, and the date on it is October 2026. go slay your memory errors, mwah 💋✨🎀