vfs_lock_file(9)

💅 vfs_lock_file(9) — your fave file byte range lock, straight from the Kernel API Manual ✨

okay so bestie, welcome to vfs_lock_file(9)! this is the manual page vibe, and yes it’s the Kernel API Manual one 🎀

🌸 NAME 🌸

vfs_lock_file — file byte range lock. literally what it says on the tin, no cap 💖

✨ SYNOPSIS ✨

int vfs_lock_file (struct file *filp , unsigned int cmd , struct file_lock *fl , struct file_lock *conf );

🦋 ARGUMENTS 🦋

• filp — the file to apply the lock to. main character file energy 🫶
• cmd — type of locking operation (F_SETLK, F_GETLK, etc.). pick your fighter 💅
• fl — the lock to be applied. yes bestie, this is the lock itself 🔥
• conf — place to return a copy of the conflicting lock, if found. found drama? put it here 😭

💜 DESCRIPTION 💜

okay so a caller that doesn’t care about the conflicting lock may pass NULL as the final argument. simple as that, no stress ✨

but listen: if the filesystem defines a private ->lock method, then conf will be left unchanged; so a caller that cares should initialize it to some acceptable default. don’t leave it looking at you like that 🫶

now, to avoid blocking kernel daemons, such as lockd, that need to acquire POSIX locks, the ->lock interface may return asynchronously, before the lock has been granted or denied by the underlying filesystem, if (and only if) lm_grant is set. additionally, FOP_ASYNC_LOCK in file_operations fop_flags need to be set. both things, bestie 💅

callers expecting ->lock to return asynchronously will only use F_SETLK, not F_SETLKW; they will set FL_SLEEP if (and only if) the request is for a blocking lock. okay? okay ✨

when ->lock does return asynchronously, it must return FILE_LOCK_DEFERRED, and call ->lm_grant when the lock request completes. no cap 🔥

if the request is for non-blocking lock, the file system should return FILE_LOCK_DEFERRED, then try to get the lock and call the callback routine with the result. if the request timed out, the callback routine will return a nonzero return code, and the file system should release the lock. periodt 💀

the file system is also responsible to keep a corresponding posix lock when it grants a lock, so the VFS can find out which locks are locally held and do the correct lock cleanup when required. that’s a whole responsibility, bestie 👑

and the underlying filesystem must not drop the kernel lock or call ->lm_grant before returning to the caller with a FILE_LOCK_DEFERRED return code. not before. iykyk 🚨

🌈 SEE ALSO 🌈

kernel file: ./fs/locks.c — and the whole SEE ALSO squad is:

• locks_owner_has_blockers(9)
• lease_open_conflict(9)
• locks_delete_block(9)
• posix_lock_file(9)
• posix_lock_inode_wait(9)
• inode_lease_ignore_mask(9)
• __break_lease(9)
• lease_get_mtime(9)
• __fcntl_getlease(9)
• generic_setlease(9)
• vfs_setlease(9)
• fcntl_setlease(9)
• fcntl_setdeleg(9)
• flock_lock_inode_wait(9)
• locks_lock_inode_wait(9)
• sys_flock(9)
• vfs_test_lock(9)
• locks_translate_pid(9)
• vfs_cancel_lock(9)
• vfs_inode_has_locks(9)

---

byeee bestie 💖 — source/version is ./fs, and the date on this one is October 2026 🎀✨