All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "bcodding@redhat.com" <bcodding@redhat.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"Anna.Schumaker@netapp.com" <Anna.Schumaker@netapp.com>
Subject: Re: [PATCH] NFS: Revalidate once when holding a delegation
Date: Sat, 25 Jan 2020 19:36:53 +0000	[thread overview]
Message-ID: <859c878cb9c645de0950fae54e59f8c528b54b9e.camel@hammerspace.com> (raw)
In-Reply-To: <43817735-6694-406C-A66A-485A716C7FC5@redhat.com>

On Fri, 2020-01-24 at 20:33 -0500, Benjamin Coddington wrote:
> On 24 Jan 2020, at 14:24, Trond Myklebust wrote:
> 
> > On Fri, 2020-01-24 at 09:09 -0500, Benjamin Coddington wrote:
> > 
> > This patch needs to fix nfs_force_lookup_revalidate() to avoid the
> > value NFS_DELEGATION_VERF.
> 
> I don't understand why.  Doesn't nfs_force_lookup_revalidate() just
> bump the
> directory's cache_change_attribute, which is value we don't care
> about at
> all here.  This patch just sets a magic value on the dentry's d_time
> after a
> revalidation occurs for that dentry while holding a delegation.  It
> doesn't
> care at all about the directory's change_attr.
> 
> What am I missing?

Those calls to nfs_set_verifier(dentry, nfs_save_change_attribute(dir))
are storing the parent directory cache_change_attribute() in the d_time
field of the child dentry. That's the normal value for the child dentry
verifiers of that directory when there is no delegation.

So to avoid collisions, you need to ensure that dir-
>cache_change_attribute never takes the value NFS_DELEGATION_VERF.


-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  reply	other threads:[~2020-01-25 19:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 14:09 [PATCH] NFS: Revalidate once when holding a delegation Benjamin Coddington
2020-01-24 19:24 ` Trond Myklebust
2020-01-25  1:33   ` Benjamin Coddington
2020-01-25 19:36     ` Trond Myklebust [this message]
2020-01-28 15:24       ` Benjamin Coddington

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=859c878cb9c645de0950fae54e59f8c528b54b9e.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=Anna.Schumaker@netapp.com \
    --cc=bcodding@redhat.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 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.