vfs_unlink(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

Okay bestie, welcome to vfs_unlink(9) β€” the Kernel API Manual page that’s about to unlink a filesystem object and look iconic doing it ✨ This is the group-chat rundown, no cap.


✨ NAME ✨

vfs_unlink β€” unlink a filesystem object πŸ’…

🫢 SYNOPSIS 🫢

int vfs_unlink (struct mnt_idmap *idmap , struct inode *dir , struct
dentry *dentry , struct delegated_inode *delegated_inode );

πŸ‘‘ ARGUMENTS πŸ‘‘

  • idmap β€” the idmap of the mount the inode was found from, iykyk πŸ¦‹
  • dir β€” parent directory, the home base of this whole operation 🏠
  • dentry β€” victim πŸ’€ literally the victim, that’s the word
  • delegated_inode β€” returns victim inode, if the inode is delegated. So it hands you back the victim inode when there’s a delegation situation πŸ‘€

🌸 DESCRIPTION 🌸

The caller must hold dir->i_rwsem exclusively. Not shared. Not β€œkinda.” Exclusively, periodt. πŸ’…

If vfs_unlink discovers a delegation, it will return -EWOULDBLOCK and return a reference to the inode in delegated_inode. The caller should then break the delegation on that inode and retry. Because breaking a delegation may take a long time, the caller should drop dir->i_rwsem before doing so. 😭 This is the part where you don’t just sit there holding the lock β€” drop it first, then go break that delegation, then retry. Highkey important.

Alternatively, a caller may pass NULL for delegated_inode. This may be appropriate for callers that expect the underlying filesystem not to be NFS exported. So if NFS export isn’t in the picture, NULL is giving lowkey valid 🫢

If the inode has been found through an idmapped mount, the idmap of the vfsmount must be passed through idmap. This function will then take care to map the inode according to idmap before checking permissions. On non-idmapped mounts or if permission checking is to be performed on the raw inode, simply pass nop_mnt_idmap. That’s the vibe check for idmapped mounts 🌈


πŸ”₯ SEE ALSO πŸ”₯

Kernel file ./fs/namei.c β€” and bestie, this list is long but literally iconic, every single one is here:

check_acl(9), acl_permission_check(9), generic_permission(9), do_inode_permission(9), sb_permission(9), inode_permission(9), path_get(9), path_put(9), path_connected(9), try_to_unlazy(9), try_to_unlazy_next(9), complete_walk(9), may_follow_link(9), safe_hardlink_source(9), may_linkat(9), may_create_in_sticky(9), lookup_fast(9), start_dirop(9), end_dirop(9), kern_path_parent(9), vfs_path_parent_lookup(9), vfs_path_lookup(9), try_lookup_noperm(9), lookup_noperm(9), lookup_one(9), lookup_one_unlocked(9), lookup_one_positive_killable(9), lookup_one_positive_unlocked(9), lookup_noperm_unlocked(9), start_creating(9), start_removing(9), start_creating_killable(9), start_removing_killable(9), start_creating_noperm(9), start_removing_noperm(9), start_creating_dentry(9), start_removing_dentry(9), __start_renaming(9), start_renaming(9), start_renaming_dentry(9), start_renaming_two_dentries(9), vfs_prepare_mode(9), vfs_create(9), atomic_open(9), vfs_lookup_open(9), vfs_tmpfile(9), kernel_tmpfile_open(9), end_creating_path(9), dentry_create(9), vfs_mknod(9), vfs_mkdir(9), vfs_rmdir(9), vfs_symlink(9), vfs_link(9), vfs_rename(9), vfs_readlink(9), vfs_get_link(9), page_get_link(9), page_put_link(9) πŸ‘‘


This page is from ./fs, dated October 2026, and it’s the vfs_unlink(9) manual page β€” slay, stay safe, hold that dir->i_rwsem exclusively bestie πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from