debugfs_file_get(9)

📦 version 7.3.1, in nixpkgs unstable

✨ debugfs_file_get(9) ✨

ok so this is a page from the Kernel API Manual — yes bestie, the kernel has its own manual and it's kind of iconic 💅

🎀 NAME 🎀

debugfs_file_get — marks the beginning of file data access. that's it, that's the whole vibe 🫶

🌸 SYNOPSIS 🌸

int debugfs_file_get (struct dentry *dentry );

💖 ARGUMENTS 💖

  • dentry — the dentry object whose data is being accessed. like, the actual file-handle-from-the-kernel's-perspective thing you're about to poke at 🦋

🌈 DESCRIPTION 🌈

okay so here's the tea ☕ — up to a matching call to debugfs_file_put, any successive call into the file removing functions debugfs_remove and debugfs_remove_recursive will block. literally just sit there. no cap.

and the reason that's actually good news? since the associated private file data may only get freed after a successful return of any of the removal functions, you may safely access it after a successful call to debugfs_file_get without worrying about lifetime issues. bestie you are SAFE. the data is not going anywhere on you 🫶✨

now, the vibes check:

  • if -EIO is returned, the file has already been removed and thus, it is not safe to access any of its data. do not pass go. do not touch the data. 💀
  • if, on the other hand, it is allowed to access the file data, zero is returned. slay. go read your data 🔥
fr fr, always check that return value. -EIO means the file is gone-gone and touching its data is straight-up undefined territory 🙈

👑 SEE ALSO 👑

and that's the whole page, bestie 💜 this one lives in ./fs/debugfs and the version is dated October 2026 — so like, future-core of them ngl. mwah, go forth and debugfs_file_get responsibly 🎀✨

📦 where this page comes from