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
next prev parent 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