On May 21, 2012, at 12:16 PM, J. Bruce Fields wrote:
> On Mon, May 21, 2012 at 12:11:48PM -0400, Chuck Lever wrote:
>>
>> On May 21, 2012, at 12:08 PM, J. Bruce Fields wrote:
>>
>>> On Fri, May 18, 2012 at 06:06:33PM -0400, Chuck Lever wrote:
>>>> @@ -3937,8 +3937,13 @@ static void nfs4_construct_boot_verifier(struct nfs_client *clp,
>>>> {
>>>> __be32 verf[2];
>>>>
>>>> - verf[0] = (__be32)clp->cl_boot_time.tv_sec;
>>>> - verf[1] = (__be32)clp->cl_boot_time.tv_nsec;
>>>> + if (test_bit(NFS4CLNT_PURGE_STATE, &clp->cl_state)) {
>>>> + verf[0] = (__be32)CURRENT_TIME.tv_sec;
>>>> + verf[1] = (__be32)CURRENT_TIME.tv_nsec;
>>>
>>> I suppose it's pretty unlikely this could happen within a jiffy of
>>> setting cl_boot_time?
>>
>> Boot time has nanosecond resolution. I'm pretty sure we are safe here.
>
> CURRENT_TIME is only updated every jiffy. It would still have to happen
> ridiculously fast, but I think that's milliseconds rather than
> nanoseconds.
>
>>> Would it be simpler to use some special value (all-zeros?) instead?
>>
>> We'd have to pick a value that was guaranteed never to be a valid time stamp.
>
> A client that thinks it's currently Jan. 1 1970 probably has bigger
> problems.
>
> I dunno, your call.
Using an out-of-date timestamp (such as all zeroes) could work. We'd just have to build an appropriate constant.
Trond, do you remember why you liked CURRENT_TIME?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
