iopt_area_add_access(9)

📦 version 7.3.1, in nixpkgs unstable

💖 iopt_area_add_access(9) 💖

Okay bestie, welcome to the Kernel API Manual, section 9 — no cap, this is the real one. Today's main character is iopt_area_add_access, and she's here to record an in-kernel access for PFNs. The original page says "in-knerel" and honestly? iconic typo, we stan, but it means in-kernel. 🫶

✨ SYNOPSIS ✨

int iopt_area_add_access (struct iopt_area *area , unsigned long
start_index , unsigned long last_index , struct page **out_pages ,
unsigned int flags , bool lock_area );

Like, that's the whole signature, copy-pasted exactly, no edits, periodt. 👑

🌸 ARGUMENTS 🌸

  • area — the source of the PFNs. She's where the pages come from, the main character of the supply chain. 💅
  • start_index — first page index. Where the party starts. 🎀
  • last_index — inclusive last page index. Yes bestie, inclusive — she's invited too. 🙈
  • out_pages — output list of struct page's representing the PFNs. You hand her a spot and she fills it in for you. ✨
  • flags — the IOMMUFD_ACCESS_RW_* flags. Flags gonna flag. 🚩
  • lock_area — fail userspace munmap on this area. Basically a "do not disturb" sign on the door. 🔒

🦋 DESCRIPTION 🦋

So what she actually does: she records that an in-kernel access is gonna be accessing those pages, makes sure they are pinned, and then returns the PFNs as a simple list of 'struct page *'. Lowkey elegant, highkey essential. 🌈

💀 Real talk though: this should be undone through a matching call to iopt_area_remove_access. Don't leave her hanging — always pair your access, bestie. Not me stressing about unbalanced calls at 3am. 😭

👑 SEE ALSO 👑

The kernel file lives at ./drivers/iommu/iommufd/pages.c — go read her, she's giving lore. 📖

💖 slay, that's the whole page 💖

Shoutout to the source, ./drivers/iommu/iommufd, and to October 2026 for the date — bookmarking it, gonna be iconic. 🎀🦋⭐

📦 where this page comes from