All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] nfsd: fix potential race in nfs4_find_file
Date: Thu, 05 Jan 2023 15:43:58 -0500	[thread overview]
Message-ID: <6ef7caa1b21f7fc2edf2722e504c1b18ff3a6023.camel@kernel.org> (raw)
In-Reply-To: <4255172A-EFB5-48B4-B2EF-700C10862427@oracle.com>

On Thu, 2023-01-05 at 14:46 +0000, Chuck Lever III wrote:
> 
> > On Jan 5, 2023, at 7:18 AM, Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > Even though there is a WARN_ON_ONCE check, it seems possible for
> > nfs4_find_file to race with the destruction of an fi_deleg_file while
> > trying to take a reference to it.
> > 
> > put_deleg_file is done while holding the fi_lock. Take and hold it
> > when dealing with the fi_deleg_file in nfs4_find_file.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/nfsd/nfs4state.c | 16 ++++++++++------
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> > 
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index b68238024e49..3df3ae84bd07 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -6417,23 +6417,27 @@ nfsd4_lookup_stateid(struct nfsd4_compound_state *cstate,
> > static struct nfsd_file *
> > nfs4_find_file(struct nfs4_stid *s, int flags)
> > {
> > +	struct nfsd_file *ret = NULL;
> > +
> > 	if (!s)
> > 		return NULL;
> > 
> > 	switch (s->sc_type) {
> > 	case NFS4_DELEG_STID:
> > -		if (WARN_ON_ONCE(!s->sc_file->fi_deleg_file))
> > -			return NULL;
> > -		return nfsd_file_get(s->sc_file->fi_deleg_file);
> > +		spin_lock(&s->sc_file->fi_lock);
> > +		if (!WARN_ON_ONCE(!s->sc_file->fi_deleg_file))
> 
> You'd think this would be a really really hard race to hit.
> 
> What I'm wondering, though, is whether the WARN_ON_ONCE should
> be dropped by this patch. I've never seen it fire.
> 
> 

I have:

    https://bugzilla.redhat.com/show_bug.cgi?id=1997177

It's possible though that those WARNs are fallout from other bugs in the
delegation handling, but it's hard to know for sure. I think we ought to
keep it there for now.

> > +			ret = nfsd_file_get(s->sc_file->fi_deleg_file);
> > +		spin_unlock(&s->sc_file->fi_lock);
> > +		break;
> > 	case NFS4_OPEN_STID:
> > 	case NFS4_LOCK_STID:
> > 		if (flags & RD_STATE)
> > -			return find_readable_file(s->sc_file);
> > +			ret = find_readable_file(s->sc_file);
> > 		else
> > -			return find_writeable_file(s->sc_file);
> > +			ret = find_writeable_file(s->sc_file);
> > 	}
> > 
> > -	return NULL;
> > +	return ret;
> > }
> > 
> > static __be32
> > -- 
> > 2.39.0
> > 
> 
> --
> Chuck Lever
> 
> 
> 

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2023-01-05 20:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 12:18 [PATCH] nfsd: fix potential race in nfs4_find_file Jeff Layton
2023-01-05 14:46 ` Chuck Lever III
2023-01-05 20:43   ` Jeff Layton [this message]
2023-01-05 21:36     ` Chuck Lever III
2023-01-05 23:05 ` NeilBrown
2023-01-06 11:58   ` Jeff Layton
2023-01-06 12:19   ` Jeff Layton
2023-01-07 10:39     ` NeilBrown

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=6ef7caa1b21f7fc2edf2722e504c1b18ff3a6023.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=chuck.lever@oracle.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.