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

[Eric Sandeen]

On 11/17/13, 1:48 PM, Dave Chinner wrote:
> On Fri, Nov 15, 2013 at 11:55:20AM -0600, Eric Sandeen wrote:
>> 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?"
> 
> Especially as it requires 2^32 modifications to first be made to the
> file before there's even the possibility of a high word race on a
> read and then there's only one increment we could race with before
> it doesn't chnge again for another 2^32 modifications.
> 
> Hence, at 1 in 4 billion modifications potentially causing a problem,
> I'd agree with the "so rare we don't care" assessment.

Ok, I'm sold.

-Eric

> Cheers,
> 
> Dave.
>