2013/1/31 J. Bruce Fields bfields@fieldses.org:
On Thu, Jan 17, 2013 at 08:52:59PM +0400, Pavel Shilovsky wrote:
If O_DENYMAND flag is specified, O_DENYREAD/WRITE/MAND flags are translated to flock's flags:
!O_DENYREAD -> LOCK_READ !O_DENYWRITE -> LOCK_WRITE O_DENYMAND -> LOCK_MAND
and set through flock_lock_file on a file.
This change only affects opens that use O_DENYMAND flag - all other native Linux opens don't care about these flags. It allow us to enable this feature for applications that need it (e.g. NFS and Samba servers that export the same directory for Windows clients, or Wine applications that access the same files simultaneously).
The use of an is_conflict callback seems unnecessarily convoluted.
If we need two different behaviors, let's just use another flag (or an extra boolean argument if we need to, or something).
Ok, we can pass "bool is_mand" to flock_lock_file that will pass it further to flock_locks_conflict.
The only caller for this new deny_lock_file is in the nfs code--I'm a little unclear why that is.
deny_lock_file is called not only in the nfs code but also in 2 places of fs/namei.c -- that enable this logic for VFS.