securityfs_create_dentry(9)
π securityfs_create_dentry(9)
okay so bestie, welcome to the Kernel API Manual, section 9 β this is the page for securityfs_create_dentry, and it's lowkey the moment you learn how to make a whole dentry exist in the securityfs filesystem. no cap, very main character of you. β¨
πΈ SYNOPSIS πΈ
struct dentry * securityfs_create_dentry (const char *name , umode_t
mode , struct dentry *parent , void *data , const struct file_operations
*fops , const struct inode_operations *iops );
literally copy that exactly, don't @ me, the spacing is part of the vibe (jk it's the signature, but still β exact π«Ά).
π ARGUMENTS π
nameβ a pointer to a string holding the name of the file you wanna create. yes, the actual name-name. πmodeβ the permission that the file should have. set it, don't guess it.parentβ a pointer to the parent dentry for this file. this should be a directory dentry if you set it, obviously. and if this parameter isNULL, then your file gets created in the root of the securityfs filesystem β iconic root placement, no folder drama. π¦dataβ a pointer to something you (the caller) will want to get back to later on. the fun part:inode.i_privatewill point to this value on theopencall. so it's like leaving yourself a little note and the kernel delivers it. πfopsβ a pointer to astruct file_operationsthat should be used for this file. this is the whole personality of your file, fr fr.iopsβ a point to a struct ofinode_operationsthat should be used for this file/dir. (yes the original says "a point to" β we're keeping the lore π)
β¨ DESCRIPTION β¨
so this is the basic "create a file/dir/symlink" function for securityfs. it gives you a wide range of flexibility in creating a file, or a directory β tho if you actually want a directory, the securityfs_create_dir function is recommended to be used instead. consider that a friendly nudge, bestie. π
this function returns a pointer to a dentry if it succeeds. and listen β that pointer must be passed to the securityfs_remove function when the file is to be removed. because there is no automatic cleanup that happens if your module is unloaded. you are responsible here. you. not the kernel. you. π that's the whole assignment.
if an error occurs, the function will return the error value (via ERR_PTR). so vibe check that return value, always.
π and if securityfs is not enabled in the kernel, the value -ENODEV is returned. that's it, that's the whole mood.
π SEE ALSO π
Kernel file ./security/inode.c β go read it, iykyk β plus these iconic siblings:
securityfs_create_file(9)securityfs_create_dir(9)securityfs_create_symlink(9)securityfs_remove(9)
π SIGN-OFF π
that's the whole page, bestie β brought to you by the source ./security and dated October 2026, living under the securityfs_create_dentry(9) banner the whole time. slay, go create some dentries responsibly, and remember: securityfs_remove is your bestie too. periodt. π
β¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms