All of lore.kernel.org
 help / color / mirror / Atom feed
From: "NeilBrown" <neilb@suse.de>
To: "Chuck Lever III" <chuck.lever@oracle.com>
Cc: "Jeff Layton" <jlayton@kernel.org>,
	"Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 5/8] NFSD: reduce locking in nfsd_lookup()
Date: Thu, 07 Jul 2022 11:29:09 +1000	[thread overview]
Message-ID: <165715734903.17141.8779762171235676843@noble.neil.brown.name> (raw)
In-Reply-To: <0A6DEF8A-232B-45FE-8A45-C403DE4E4342@oracle.com>

On Thu, 07 Jul 2022, Chuck Lever III wrote:
> > +		/* We want to keep the directory locked until we've had a chance
> > +		 * to acquire a delegation if appropriate, so request that
> > +		 * nfsd_lookup() hold on to the lock.
> > 		 */
> > 		status = nfsd_lookup(rqstp, current_fh,
> > -				     open->op_fname, open->op_fnamelen, *resfh);
> > +				     open->op_fname, open->op_fnamelen, *resfh,
> > +				     true);
> > +		if (!status) {
> > +			/* NFSv4 protocol requires change attributes even though
> > +			 * no change happened.
> > +			 */
> > +			fh_fill_pre_attrs(current_fh);
> > +			fh_fill_post_attrs(current_fh);
> 
> If this is really correct, the comment should also state that
> no concurrent changes to the parent are possible during
> the lookup, and thus the pre and post attributes are expected
> to be the same always.

The earlier comment notes that nfsd_lookup() is called in a way in which
it takes and keeps the lock - that should imply that no other changes
can happen.  But with such insane looking code, it doesn't hurt to be
extra explicit.

> 
> Otherwise, this code paragraph looks just a little insane ;-)
> 
:-)

Thanks,
NeilBrown

  reply	other threads:[~2022-07-07  1:29 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06  4:18 [PATCH 0/8] NFSD: clean up locking NeilBrown
2022-07-06  4:18 ` [PATCH 6/8] NFSD: use explicit lock/unlock for directory ops NeilBrown
2022-07-06 14:05   ` Jeff Layton
2022-07-06 16:29   ` Chuck Lever III
2022-07-15 16:11   ` Jeff Layton
2022-07-15 18:22     ` Jeff Layton
2022-07-17 23:59       ` NeilBrown
2022-07-17 23:43     ` NeilBrown
2022-07-06  4:18 ` [PATCH 8/8] NFSD: discard fh_locked flag and fh_lock/fh_unlock NeilBrown
2022-07-06 14:12   ` Jeff Layton
2022-07-06  4:18 ` [PATCH 7/8] NFSD: use (un)lock_inode instead of fh_(un)lock for file operations NeilBrown
2022-07-06 14:10   ` Jeff Layton
2022-07-06 16:30   ` Chuck Lever III
2022-07-07  1:33     ` NeilBrown
2022-07-06  4:18 ` [PATCH 2/8] NFSD: change nfsd_create() to unlock directory before returning NeilBrown
2022-07-06 13:24   ` Jeff Layton
2022-07-06 16:29   ` Chuck Lever III
2022-07-06  4:18 ` [PATCH 1/8] NFSD: drop rqstp arg to do_set_nfs4_acl() NeilBrown
2022-07-06 13:17   ` Jeff Layton
2022-07-06  4:18 ` [PATCH 4/8] NFSD: only call fh_unlock() once in nfsd_link() NeilBrown
2022-07-06 13:31   ` Jeff Layton
2022-07-06 16:29   ` Chuck Lever III
2022-07-06  4:18 ` [PATCH 3/8] NFSD: always drop directory lock in nfsd_unlink() NeilBrown
2022-07-06 13:30   ` Jeff Layton
2022-07-06  4:18 ` [PATCH 5/8] NFSD: reduce locking in nfsd_lookup() NeilBrown
2022-07-06 13:47   ` Jeff Layton
2022-07-07  1:26     ` NeilBrown
2022-07-06 16:29   ` Chuck Lever III
2022-07-07  1:29     ` NeilBrown [this message]
2022-07-06 16:29 ` [PATCH 0/8] NFSD: clean up locking Chuck Lever III
2022-07-12  2:33   ` NeilBrown
2022-07-12 14:17     ` Chuck Lever III
2022-07-13  4:32       ` NeilBrown
2022-07-13 14:15         ` Chuck Lever III
2022-07-13 19:13           ` Jeff Layton
2022-07-14 14:32             ` Chuck Lever III
2022-07-15  2:36           ` NeilBrown
2022-07-15 13:01             ` Jeff Layton
2022-07-15 13:53               ` Jeff Layton
2022-07-15 14:06             ` Chuck Lever III

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=165715734903.17141.8779762171235676843@noble.neil.brown.name \
    --to=neilb@suse.de \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --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 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.