On Mon, 2012-05-21 at 12:24 -0400, Chuck Lever wrote:
> 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.
Better yet: use an invalid timestamp. Anything with a tv_nsec >=
1000000000L would work.
> Trond, do you remember why you liked CURRENT_TIME?
I don't think that I was the one who chose CURRENT_TIME for the
purge_state. I'm fine with anything that is guaranteed to always differ
from clp->cl_boot_time.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
