public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Neil Brown <neilb@suse.de>, Olga Kornievskaia <kolga@netapp.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	Youzhong Yang <youzhong@gmail.com>,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] nfsd: plug some filecache refcount leaks
Date: Wed, 10 Jul 2024 10:39:08 -0400	[thread overview]
Message-ID: <dba5e87299d90d3dce0c055046c304196b0941b0.camel@kernel.org> (raw)
In-Reply-To: <Zo6cQ874llzn/Flw@tissot.1015granger.net>

On Wed, 2024-07-10 at 10:35 -0400, Chuck Lever wrote:
> On Wed, Jul 10, 2024 at 09:05:30AM -0400, Jeff Layton wrote:
> > Youzhong Yang sent an email to the list (along with some draft
> > patches)
> > that indicated some nfsd_file refcount leaks. I went crawling over
> > the
> > filecache code (again) and found a couple of places where we didn't
> > put
> > references when we should. I'm not sure if it'll fix the problem
> > they
> > reported, but they are bugs.
> > 
> > Plus, let's start counting nfsd_file allocations. The last patch
> > adds
> > support for this.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > Jeff Layton (3):
> >       nfsd: fix refcount leak when failing to hash nfsd_file
> >       nfsd: fix refcount leak when file is unhashed after being
> > found
> >       nfsd: count nfsd_file allocations
> > 
> >  fs/nfsd/filecache.c | 14 +++++++++++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> > ---
> > base-commit: 24decb225ed20a5ba46a79f4609e109cb0e4a359
> > change-id: 20240710-nfsd-next-01e2afdebb31
> > 
> > Best regards,
> > -- 
> > Jeff Layton <jlayton@kernel.org>
> > 
> 
> I've browsed these, they seem straightforward.
> 
> Since this is the week before a merge window, I would like to save
> these and Youzhong's patch for v6.12. The Fixes: tags will get them
> pulled back into the stable kernels once they are merged.
> 
> 'Salright?
> 

Agreed. Leaks suck, but they (usually) aren't fatal, and interactions
in the filecache can be...subtle. I wouldn't mind a bit more testing
before we send this on.

Thanks!
-- 
Jeff Layton <jlayton@kernel.org>

      reply	other threads:[~2024-07-10 14:39 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
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 [this message]

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=dba5e87299d90d3dce0c055046c304196b0941b0.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