2013/2/5 J. Bruce Fields <bfields@xxxxxxxxxxxx>: > On Tue, Feb 05, 2013 at 03:45:31PM +0400, Pavel Shilovsky wrote: >> 2013/1/31 J. Bruce Fields <bfields@xxxxxxxxxxxx>: >> > 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. > > Oops, apologies, I overlooked those somehow. > > What prevents somebody else from grabbing a lock on a newly-created file > before we grab our own lock? > > I couldn't tell on a quick look whether we hold some lock that prevents > that. Nothing prevents it. If somebody grabbed a share mode lock on a file before we call deny_lock_file, we simply close this file and return -ETXTBSY. We can't grab it before atomic_open because we don't have an inode there. Anyway, we can't make it atomic for VFS without big code changes, but for CIFS and NFS it is already atomic with the discussed patch. -- Best regards, Pavel Shilovsky. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
