ecryptfs_decrypt_page(9)

📦 version 7.3.1, in nixpkgs unstable

💖 ecryptfs_decrypt_page 💖

Okay bestie, welcome to the ecryptfs_decrypt_page(9) page from the Kernel API Manual — this is the crypt girly that un-scrambles your eCryptfs pages, and honestly? She's doing the most. Let's get into it ✨

🌸 NAME 🌸

ecryptfs_decrypt_page —

(no cap, that's literally the whole thing, the original says nothing else here and I refuse to invent lore 🙈)

🎀 SYNOPSIS 🎀

int ecryptfs_decrypt_page (struct folio *folio );

🦋 ARGUMENTS 🦋

  • folio — a Folio that's been mapped from the eCryptfs inode for the file 💅. Anything read and decrypted from the lower file gets written straight into this page — so this is the destination, the main character, the place where the good stuff lands 🫶

👑 DESCRIPTION 👑

So like, this function decrypts an eCryptfs page 💖. And the way it does that is on a per-extent basis — not the whole page at once, an extent at a time, periodt.

Now the important vibe check here: eCryptfs pages can totally straddle the lower pages 😭 — like they don't line up neatly, and here's the iconic example the page gives us:

Say the file was created on a machine with an 8K page size (which means you get an 8K header). Then the file gets copied onto a host with a 32K page size. Now when you're reading page 0 of the eCryptfs file, 24K of page 0 of the lower file gets read and decrypted, and then 8K of page 1 of the lower file gets read and decrypted. Two pages, one read, it's giving teamwork 🌈

Returns zero on success; negative on error ⭐ (so like, check the return value, bestie, fr fr 💀)

💫 SEE ALSO 💫

Kernel file ./fs/ecryptfs/crypto.c — and then the whole group chat, alphabetically-by-nothing but here they all are, every single one 🔥:

✨ that's the whole page, you ate that ✨ This little gem lives in ./fs/ecryptfs, it's dated October 2026, and it answers to the name ecryptfs_decrypt_page(9) — mwah 💋🎀

📦 where this page comes from