Re: nfsd4_locku / nfs4_free_lock_stateid question

[Jeff Layton <jeff.layton@primarydata.com>]

On Sun, 13 Jul 2014 04:00:47 -0700
Christoph Hellwig <hch@infradead.org> 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@primarydata.com>