On Sun, 13 Jul 2014 04:00:47 -0700 Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > Hi Jeff, > > while reviewing some of your patches I've started wondering about > some v4 locking code. > > In nfsd4_locku we're doing a call to find_any_file to grab a file > structure for the lock stateid, which nfs4_free_lock_stateid tries to > close. But what guarantees that we're actually getting the same file > descriptor back? > > The nfs4_file is shared by and stateid that access a given inode, > so the first call to find_any_file might return the read/only file > structure because that's the only one available so far, while > by the time we unlock we might have a read/write and/or write-only file > available as well, which find_any_file will return. > > It seems like the lock stateid needs a pointer to the actual file > locked, and keep a reference to it independent of the nfs4_file, or am I > missing something? It is weird, but I don't think it really matters as the filp is only really used as a way to get to the inode -- it really doesn't matter which struct file we use there. find_any_file will both take a reference to and return the file, which is then eventually fput in filp_close, so there should be no refcount leak or anything. The weirdness all comes from the vfs-layer file locking interfaces, many of which take a struct file argument when they really would be fine with a struct inode. Maybe one of these days we can get around to cleaning that up. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- 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
