Re: nfsd4_locku / nfs4_free_lock_stateid question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jul 13, 2014 at 08:05:41AM -0400, Jeff Layton wrote:
> 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.

If filesystems get the file passed we should assume that they actually
use it.  In fact AFS does, but it's not NFS exportable at the moment,
and ceph does in a debug printk.  I'd be much happier to waste a pointer
in the lock stateid to avoid this inconsistant interface.  And it would
allow to kill find_any_fileas well..

--
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




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux