From: Jeff Layton <jlayton@kernel.org>
To: Youzhong Yang <youzhong@gmail.com>
Cc: Chuck Lever <chuck.lever@oracle.com>, Neil Brown <neilb@suse.de>,
Olga Kornievskaia <kolga@netapp.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] nfsd: fix refcount leak when failing to hash nfsd_file
Date: Thu, 11 Jul 2024 13:53:12 -0400 [thread overview]
Message-ID: <50afe4a63be26a946257c335188e230c86beb148.camel@kernel.org> (raw)
In-Reply-To: <CADpNCvYknMBXf+V=vBLkjOMhTFRN-3o2R9A2c5J4POuaD49kMw@mail.gmail.com>
On Thu, 2024-07-11 at 13:05 -0400, Youzhong Yang wrote:
> Shouldn't we have fh_put(fhp) before 'retry'?
>
A subtle question, actually...
It probably wouldn't hurt to do that, but I don't think it's required.
The main reason we call fh_put is to force a second call to
nfsd_set_fh_dentry. IOW, we want to redo the lookup by filehandle and
find the inode.
In the EEXIST case, presumably we have found the inode but we raced
with another task in setting an nfsd_file for it in the hash. That's
different from the case where the thing was unhashed or we got an
EOPENSTALE. So, I think we probably don't require refinding the inode
in that case.
More pointedly, I'm not sure this particular case is actually possible.
The entries are hashed on the inode pointer value, and we're searching
and inserting into the hash under the i_lock.
Chuck, thoughts?
> On Wed, Jul 10, 2024 at 9:06 AM Jeff Layton <jlayton@kernel.org>
> wrote:
> >
> > At this point, we have a new nf that we couldn't properly insert
> > into
> > the hashtable. Just free it before retrying, since it was never
> > hashed.
> >
> > Fixes: c6593366c0bf ("nfsd: don't kill nfsd_files because of lease
> > break error")
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/nfsd/filecache.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> > index f84913691b78..4fb5e8546831 100644
> > --- a/fs/nfsd/filecache.c
> > +++ b/fs/nfsd/filecache.c
> > @@ -1038,8 +1038,10 @@ nfsd_file_do_acquire(struct svc_rqst *rqstp,
> > struct svc_fh *fhp,
> > if (likely(ret == 0))
> > goto open_file;
> >
> > - if (ret == -EEXIST)
> > + if (ret == -EEXIST) {
> > + nfsd_file_free(nf);
> > goto retry;
> > + }
> > trace_nfsd_file_insert_err(rqstp, inode, may_flags, ret);
> > status = nfserr_jukebox;
> > goto construction_err;
> >
> > --
> > 2.45.2
> >
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2024-07-11 17:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 13:05 [PATCH 0/3] nfsd: plug some filecache refcount leaks Jeff Layton
2024-07-10 13:05 ` [PATCH 1/3] nfsd: fix refcount leak when failing to hash nfsd_file Jeff Layton
2024-07-11 17:05 ` Youzhong Yang
2024-07-11 17:53 ` Jeff Layton [this message]
2024-07-11 18:16 ` Chuck Lever III
2024-07-11 18:20 ` Jeff Layton
2024-07-11 18:27 ` Chuck Lever III
2024-07-10 13:05 ` [PATCH 2/3] nfsd: fix refcount leak when file is unhashed after being found Jeff Layton
2024-07-10 13:05 ` [PATCH 3/3] nfsd: count nfsd_file allocations Jeff Layton
2024-07-10 14:35 ` [PATCH 0/3] nfsd: plug some filecache refcount leaks Chuck Lever
2024-07-10 14:39 ` Jeff Layton
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=50afe4a63be26a946257c335188e230c86beb148.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=kolga@netapp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=tom@talpey.com \
--cc=youzhong@gmail.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