From: Christoph Hellwig <hch@infradead.org>
To: Jeff Layton <jlayton@primarydata.com>
Cc: bfields@fieldses.org, hch@infradead.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 09/10] nfsd: Fix delegation revocation
Date: Wed, 16 Jul 2014 11:30:47 -0700 [thread overview]
Message-ID: <20140716183047.GA19002@infradead.org> (raw)
In-Reply-To: <1405521125-2303-10-git-send-email-jlayton@primarydata.com>
> -/* Called under the state lock. */
You're removing a comment hat only becomes true after your patch :)
But I agree that it's obsolete, the lockdep_assert_held is better than
the comment.
> @@ -685,11 +686,10 @@ static void revoke_delegation(struct nfs4_delegation *dp)
> struct nfs4_client *clp = dp->dl_stid.sc_client;
>
> if (clp->cl_minorversion == 0)
> - destroy_delegation(dp);
> + destroy_revoked_delegation(dp);
Seems a little confusing as we didn't turn the code into a REVOKED_DELEG
stateid type yet, but given that destroy_revoked_delegation doesn't
care this is probably fine.
> else {
> - unhash_delegation(dp);
> dp->dl_stid.sc_type = NFS4_REVOKED_DELEG_STID;
> - list_add(&dp->dl_recall_lru, &clp->cl_revoked);
> + list_move(&dp->dl_recall_lru, &clp->cl_revoked);
What protects access to cl_revoked, btw?
Otherwise this looks fine to me,
Reviewed-by: Christoph Hellwig <hch@lst.de>
(would have been a little nicer to read if you had kept
destroy_revoked_delegation, otherwise diff obsfucates the fact that it
didn't change at all..
next prev parent reply other threads:[~2014-07-16 18:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 14:31 [PATCH v2 0/8] nfsd: more delegation fixes to prepare for client_mutex removal Jeff Layton
2014-07-16 14:31 ` [PATCH v2 01/10] nfsd: eliminate nfsd4_init_callback Jeff Layton
2014-07-16 14:31 ` [PATCH v2 02/10] nfsd: Avoid taking state_lock while holding inode lock in nfsd_break_one_deleg Jeff Layton
2014-07-17 1:34 ` J. Bruce Fields
2014-07-17 10:57 ` Jeff Layton
2014-07-16 14:31 ` [PATCH v2 03/10] nfsd: nfs4_alloc_init_lease should take a nfs4_file arg Jeff Layton
2014-07-16 14:31 ` [PATCH v2 04/10] nfsd: Ensure stateids remain unique until they are freed Jeff Layton
2014-07-17 18:44 ` J. Bruce Fields
2014-07-17 18:46 ` Jeff Layton
2014-07-16 14:32 ` [PATCH v2 05/10] locks: add file_has_lease to prevent delegation break races Jeff Layton
2014-07-16 14:32 ` [PATCH v2 06/10] nfsd: Protect the nfs4_file delegation fields using the fi_lock Jeff Layton
2014-07-16 18:09 ` Christoph Hellwig
2014-07-16 19:04 ` Jeff Layton
2014-07-17 14:55 ` Christoph Hellwig
2014-07-17 15:31 ` Jeff Layton
2014-07-16 14:32 ` [PATCH v2 07/10] nfsd: Move the delegation reference counter into the struct nfs4_stid Jeff Layton
2014-07-16 14:32 ` [PATCH v2 08/10] nfsd: Simplify stateid management Jeff Layton
2014-07-16 18:10 ` Christoph Hellwig
2014-07-16 14:32 ` [PATCH v2 09/10] nfsd: Fix delegation revocation Jeff Layton
2014-07-16 18:30 ` Christoph Hellwig [this message]
2014-07-16 19:16 ` Jeff Layton
2014-07-17 9:22 ` Christoph Hellwig
2014-07-16 14:32 ` [PATCH v2 10/10] nfsd: Convert delegation counter to an atomic_long_t type Jeff Layton
2014-07-16 18:11 ` Christoph Hellwig
2014-07-16 14:33 ` [PATCH v2 0/8] nfsd: more delegation fixes to prepare for client_mutex removal Jeff Layton
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=20140716183047.GA19002@infradead.org \
--to=hch@infradead.org \
--cc=bfields@fieldses.org \
--cc=jlayton@primarydata.com \
--cc=linux-nfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox