[Top] [All Lists]

Re: [PATCH 0/5] xfs: more patches for 3.13

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 0/5] xfs: more patches for 3.13
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 15 Nov 2013 11:19:55 -0600
Cc: Ben Myers <bpm@xxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131114011610.GM6188@dastard>
References: <1383280040-21979-1-git-send-email-david@xxxxxxxxxxxxx> <20131106230133.GX1935@xxxxxxx> <20131107015706.GM6188@dastard> <5282D2D3.3040601@xxxxxxxxxxx> <20131114011610.GM6188@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
On 11/13/13, 7:16 PM, Dave Chinner wrote:

> That's client side, not server side, so that's the NFS client inode
> it is locking, not the server side XFS inode.

Ah, geez, you're right. (x3)


> Server side, where i_version is pulled out of an XFS inode:
> $ git grep i_version fs/nfsd
> fs/nfsd/nfs3xdr.c:      fhp->fh_post_change = 
> fhp->fh_dentry->d_inode->i_version;
> fs/nfsd/nfs4xdr.c:              write64(p, inode->i_version);
> fs/nfsd/nfsfh.h:                fhp->fh_pre_change = inode->i_version;
> $
> the nfsfh.h hit is in fill_pre_wcc(), which appears to be called
> under i_mutex but not i_lock. The xdr encoding functions don't
> appear to be holding i_lock, and may be holding i_mutex, but I
> haven't looked that far.

I'm still not sure how 

> Cheers,
> Dave.

<Prev in Thread] Current Thread [Next in Thread>