LOCK_MAY_WRITE(9) The Linux VFS LOCK_MAY_WRITE(9)NAME
lock_may_write - checks that the region is free of locks
SYNOPSIS
int lock_may_write(struct inode * inode, loff_t start, unsigned long len);
ARGUMENTS
inode
the inode that is being written
start
the first byte to write
len
the number of bytes to write
DESCRIPTION
Emulates Windows locking requirements. Whole-file mandatory locks (share modes) can prohibit a write and byte-range POSIX locks can
prohibit a write if they overlap.
N.B. this function is only ever called from knfsd and ownership of locks is never checked.
COPYRIGHT Kernel Hackers Manual 3.10 June 2014 LOCK_MAY_WRITE(9)
Check Out this Related Man Page
VFS_LOCK_FILE(9) The Linux VFS VFS_LOCK_FILE(9)NAME
vfs_lock_file - file byte range lock
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
cmd
type of locking operation (F_SETLK, F_GETLK, etc.)
fl
The lock to be applied
conf
Place to return a copy of the conflicting lock, if found.
DESCRIPTION
A caller that doesn't care about the conflicting lock may pass NULL as the final argument.
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.
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. 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. When ->lock
does return asynchronously, it must return FILE_LOCK_DEFERRED, and call ->lm_grant when the lock request completes. 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. 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. 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.
COPYRIGHT Kernel Hackers Manual 3.10 June 2014 VFS_LOCK_FILE(9)