From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: trond.myklebust@netapp.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 09/14] NFS: Force server to drop NFSv4 state
Date: Mon, 21 May 2012 12:16:46 -0400 [thread overview]
Message-ID: <20120521161646.GJ24299@fieldses.org> (raw)
In-Reply-To: <F7B056E4-D6FC-450B-98E2-129C051CFAE7@oracle.com>
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.
--b.
next prev parent reply other threads:[~2012-05-21 16:16 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-18 22:05 [PATCH 00/14] UCS pre-requisites for 3.5 Chuck Lever
2012-05-18 22:05 ` [PATCH 01/14] NFS: Fix comment misspelling in struct nfs_client definition Chuck Lever
2012-05-18 22:05 ` [PATCH 02/14] NFS: Use proper naming conventions for NFSv4.1 server scope fields Chuck Lever
2012-05-19 21:08 ` Myklebust, Trond
2012-05-18 22:05 ` [PATCH 03/14] NFS: Use proper naming conventions for nfs_client.impl_id field Chuck Lever
2012-05-21 15:06 ` Adamson, Dros
2012-05-18 22:05 ` [PATCH 04/14] NFS: Use proper naming conventions for the nfs_client.net field Chuck Lever
2012-05-18 22:05 ` [PATCH 05/14] NFS: Clean up return code checking in nfs4_proc_exchange_id() Chuck Lever
2012-05-21 15:10 ` Adamson, Dros
2012-05-21 15:19 ` Chuck Lever
2012-05-18 22:06 ` [PATCH 06/14] NFS: Remove nfs_unique_id Chuck Lever
2012-05-18 22:06 ` [PATCH 07/14] NFS: Don't swap bytes in nfs4_construct_boot_verifier() Chuck Lever
2012-05-21 15:40 ` J. Bruce Fields
2012-05-21 15:47 ` Chuck Lever
2012-05-21 15:51 ` J. Bruce Fields
2012-05-18 22:06 ` [PATCH 08/14] NFS: Add NFSDBG_STATE Chuck Lever
2012-05-18 22:06 ` [PATCH 09/14] NFS: Force server to drop NFSv4 state Chuck Lever
2012-05-21 16:08 ` J. Bruce Fields
2012-05-21 16:11 ` J. Bruce Fields
2012-05-21 16:11 ` Chuck Lever
2012-05-21 16:16 ` J. Bruce Fields [this message]
2012-05-21 16:24 ` Chuck Lever
2012-05-21 16:49 ` Myklebust, Trond
2012-05-18 22:06 ` [PATCH 10/14] NFS: Always use the same SETCLIENTID boot verifier Chuck Lever
2012-05-18 22:06 ` [PATCH 11/14] NFS: Refactor nfs_get_client(): add nfs_found_client() Chuck Lever
2012-05-18 22:06 ` [PATCH 12/14] NFS: Refactor nfs_get_client(): initialize nfs_client Chuck Lever
2012-05-18 22:07 ` [PATCH 13/14] NFS: Add nfs_client behavior flags Chuck Lever
2012-05-18 22:07 ` [PATCH 14/14] NFS: EXCHANGE_ID should save the server major and minor ID Chuck Lever
-- strict thread matches above, loose matches on Subject: below --
2012-05-22 2:44 [PATCH 00/14 v2] UCS pre-requisites for 3.5 Chuck Lever
2012-05-22 2:45 ` [PATCH 09/14] NFS: Force server to drop NFSv4 state Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120521161646.GJ24299@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@netapp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.