folio_mkwrit...eck_truncate(9)

📦 version 7.3.1, in nixpkgs unstable

💅 folio_mkwrite_check_truncate(9) — from the Kernel API Manual, bestie ✨

Okay so picture this: you're in the kernel, you've got a folio, you've got an inode, and you just need to know if that folio got truncated out from under you. That's the whole gig. Welcome to the group chat 🫶

🌸 NAME 🌸

folio_mkwrite_check_truncate — literally just checks if the folio was truncated. That's it. That's the function. 💖

✨ SYNOPSIS ✨

ssize_t folio_mkwrite_check_truncate (const struct folio *folio , const
       struct inode *inode );

Look at her. Gorgeous. Returns a ssize_t, takes two const pointers because she does not modify your stuff, she's a respectful queen 👑. Also yes, the signature is wrapped across two lines in the original and we're keeping it exactly like that, no cap.

🎀 ARGUMENTS 🎀

  • folio — the folio to check. The main character of this whole operation. 🌟
  • inode — the inode to check the folio against. The vibe reference. The thing we're comparing against. 🦋

💀 RETURN 💀

So here's what you get back:

  • the number of bytes in the folio up to EOF — the happy path, the slay path 🎉
  • or -EFAULT if the folio was truncated — the sad path, the "why is this happening to me" path 😭

That's it. Two outcomes. No in-between. Periodt.

🔥 SEE ALSO 🔥

Buckle up bestie, this list is long — but every single one deserves her moment. Kernel file ./include/linux/pagemap.h is the home base for all of these:

Forty-six entries. Forty-six!! Not me counting them all. Anyway, they're all right there in ./include/linux/pagemap.h, go read them, iykyk 📚💜

Heads up bestie — the -EFAULT return is a real thing you have to handle. The folio got truncated. Don't just vibe past it. 🙈

✨ that's the whole page, mwah ✨ This one lives at ./include/linux, dated October 2026, and the page title is folio_mkwrit...eck_truncate(9) (yes the header truncates the name, iconic of it honestly). Later, bestie! 💅🎀🦋

📦 where this page comes from