public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@kernel.org>
To: Roberto Bergantinos Corpas <rbergant@redhat.com>, anna@kernel.org
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH RESEND] nfs: force drop_nlink if we have a delegation during REMOVE
Date: Mon, 20 Apr 2026 12:15:44 -0400	[thread overview]
Message-ID: <94e8705dcd4c4cee52e6c234a533fd4968ec4fb9.camel@kernel.org> (raw)
In-Reply-To: <20260420114331.700769-1-rbergant@redhat.com>

On Mon, 2026-04-20 at 13:43 +0200, Roberto Bergantinos Corpas wrote:
> commit bd4928ec799b ("NFS: Avoid changing nlink when file removes and
> attribute updates race") avoids races on attribute cache with any
> inflight RPC that may modify inode attributes (and gencount) during
> i.e. REMOVE.
> 
> However it does not take into account that REMOVE may trigger
> a delegation return which also advances gencount (via the attribute
> refresh during delegation return), and in that case the gencount
> mismatch is not due to an inflight RPC that already reflected the
> removal.
> 
> If nlink is 1 and we have a delegation before REMOVE, we should force
> the drop to ensure the VFS delivers the expected FS_DELETE_SELF
> notification.
> 
> This fixes LTP/inotify04 failure after bd4928ec799b.
> 
> Fixes: bd4928ec799b ("NFS: Avoid changing nlink when file removes and
> attribute updates race")
> Reviewed-by: Olga Kornievskaia <okorniev@redhat.com>
> Signed-off-by: Roberto Bergantinos Corpas <rbergant@redhat.com>
> ---
>  fs/nfs/dir.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index 2402f57c8e7d..bc6bbf434a21 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -1937,13 +1937,13 @@ static int nfs_dentry_delete(const struct
> dentry *dentry)
>  }
>  
>  /* Ensure that we revalidate inode->i_nlink */
> -static void nfs_drop_nlink(struct inode *inode, unsigned long
> gencount)
> +static void nfs_drop_nlink(struct inode *inode, unsigned long
> gencount, bool force)
>  {
>  	struct nfs_inode *nfsi = NFS_I(inode);
>  
>  	spin_lock(&inode->i_lock);
>  	/* drop the inode if we're reasonably sure this is the last
> link */
> -	if (inode->i_nlink > 0 && gencount == nfsi->attr_gencount)
> +	if (inode->i_nlink > 0 && (force || gencount == nfsi-
> >attr_gencount))
>  		drop_nlink(inode);
>  	nfsi->attr_gencount = nfs_inc_attr_generation_counter();
>  	nfs_set_cache_invalid(
> @@ -1961,7 +1961,7 @@ static void nfs_dentry_iput(struct dentry
> *dentry, struct inode *inode)
>  	if (dentry->d_flags & DCACHE_NFSFS_RENAMED) {
>  		unsigned long gencount = READ_ONCE(NFS_I(inode)-
> >attr_gencount);
>  		nfs_complete_unlink(dentry, inode);
> -		nfs_drop_nlink(inode, gencount);
> +		nfs_drop_nlink(inode, gencount, false);
>  	}
>  	iput(inode);
>  }
> @@ -2556,10 +2556,11 @@ static int nfs_safe_remove(struct dentry
> *dentry)
>  	trace_nfs_remove_enter(dir, dentry);
>  	if (inode != NULL) {
>  		unsigned long gencount = READ_ONCE(NFS_I(inode)-
> >attr_gencount);
> +		bool force_drop =
> nfs_have_read_or_write_delegation(inode) && inode->i_nlink == 1;
>  
>  		error = NFS_PROTO(dir)->remove(dir, dentry);
>  		if (error == 0)
> -			nfs_drop_nlink(inode, gencount);
> +			nfs_drop_nlink(inode, gencount, force_drop);
>  	} else
>  		error = NFS_PROTO(dir)->remove(dir, dentry);
>  	if (error == -ENOENT)
> @@ -2852,7 +2853,7 @@ int nfs_rename(struct mnt_idmap *idmap, struct
> inode *old_dir,
>  			new_dir, new_dentry, error);
>  	if (!error) {
>  		if (new_inode != NULL)
> -			nfs_drop_nlink(new_inode, new_gencount);
> +			nfs_drop_nlink(new_inode, new_gencount,
> false);
>  		/*
>  		 * The d_move() should be here instead of in an
> async RPC completion
>  		 * handler because we need the proper locks to move
> the dentry.  If

The right way to go about this is to push the setting of gencount from
nfs_safe_remove() down into the version-specific layer so that you can
order it correctly with the delegation return and call to
_nfs4_proc_remove().

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

  reply	other threads:[~2026-04-20 16:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-20 11:43 [PATCH RESEND] nfs: force drop_nlink if we have a delegation during REMOVE Roberto Bergantinos Corpas
2026-04-20 16:15 ` Trond Myklebust [this message]
2026-04-21 10:00 ` [PATCH v2] nfs: set gencount on protocol-specific remove Roberto Bergantinos Corpas

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=94e8705dcd4c4cee52e6c234a533fd4968ec4fb9.camel@kernel.org \
    --to=trondmy@kernel.org \
    --cc=anna@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rbergant@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox