All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@redhat.com>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "bfields@fieldses.org" <bfields@fieldses.org>,
	"kinglongmee@gmail.com" <kinglongmee@gmail.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] SUNRPC/cache: Allow garbage collection of invalid cache entries
Date: Thu, 26 Mar 2020 21:50:12 -0400	[thread overview]
Message-ID: <20200327015012.GA107036@pick.fieldses.org> (raw)
In-Reply-To: <1a0ce8bb1150835f7a25126df2524e8a8fb0e112.camel@hammerspace.com>

On Thu, Mar 26, 2020 at 09:42:19PM +0000, Trond Myklebust wrote:
> On Thu, 2020-03-26 at 16:40 -0400, bfields@fieldses.org wrote:
> > Maybe the cache_is_expired() logic should be something more like:
> > 
> > 	if (h->expiry_time < seconds_since_boot())
> > 		return true;
> > 	if (!test_bit(CACHE_VALID, &h->flags))
> > 		return false;
> > 	return h->expiry_time < seconds_since_boot();
> > 
> > So invalid cache entries (which are waiting for a reply from mountd)
> > can
> > expire, but they can't be flushed.  If that makes sense.
> > 
> > As a stopgap we may want to revert or drop the "Allow garbage
> > collection" patch, as the (preexisting) memory leak seems lower
> > impact
> > than the server hang.
> 
> I believe you were probably seeing the effect of the
> cache_listeners_exist() test, which is just wrong for all cache upcall
> users except idmapper and svcauth_gss. We should not be creating
> negative cache entries just because the rpc.mountd daemon happens to be
> slow to connect to the upcall pipes when starting up, or because it
> crashes and fails to restart correctly.
> 
> That's why, when I resubmitted this patch, I included 
> https://git.linux-nfs.org/?p=cel/cel-2.6.git;a=commitdiff;h=b840228cd6096bebe16b3e4eb5d93597d0e02c6d
> 
> which turns off that particular test for all the upcalls to rpc.mountd.

The hangs persist with that patch, but go away with the change to the
cache_is_expired() logic above.

--b.


  reply	other threads:[~2020-03-27  1:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 16:57 [PATCH] SUNRPC/cache: Allow garbage collection of invalid cache entries Trond Myklebust
2020-02-06 16:33 ` J. Bruce Fields
2020-02-07 14:25   ` Trond Myklebust
2020-02-07 18:18     ` bfields
2020-02-10 18:47       ` Trond Myklebust
2020-03-26 20:40       ` bfields
2020-03-26 21:42         ` Trond Myklebust
2020-03-27  1:50           ` J. Bruce Fields [this message]
2020-03-27 12:33             ` Trond Myklebust
2020-03-27 15:53               ` [PATCH] SUNRPC/cache: don't allow invalid entries to be flushed J. Bruce Fields
2020-03-27 16:15                 ` Chuck Lever

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=20200327015012.GA107036@pick.fieldses.org \
    --to=bfields@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=kinglongmee@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.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 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.