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

From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: Ben Myers <bpm@sgi.com>, xfs@oss.sgi.com
Subject: Re: [PATCH 0/5] xfs: more patches for 3.13
Date: Fri, 15 Nov 2013 11:55:20 -0600	[thread overview]
Message-ID: <52866008.4010309@sandeen.net> (raw)
In-Reply-To: <528657BB.8090206@sandeen.net>

On 11/15/13, 11:19 AM, Eric Sandeen wrote:
> 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)
> 
> <snip>
> 
>> 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  . . . 

ugh didn't mean to send this reply quite yet, sorry.

Not sure how we do an unlocked read on a 32-bit machine that doesn't potentially
get the wrong answer.  I talked to Bruce about it a bit; nothing jumped out at
us.  At worst (?) it seems that if you happened to race on a read at exactly
the 2^32'nd modification, you might go backwards.  

As Bruce says, even if so, maybe "so rare we don't care?"

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs