From: "J. Bruce Fields" <bfields@fieldses.org>
To: NeilBrown <neilb@suse.com>
Cc: "Wang, Alan 1. (NSB - CN/Hangzhou)" <alan.1.wang@nokia-sbell.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] SUNRPC: cache: ignore timestamp written to 'flush' file.
Date: Wed, 21 Feb 2018 19:46:52 -0500 [thread overview]
Message-ID: <20180222004652.GE6535@fieldses.org> (raw)
In-Reply-To: <877ergqsmd.fsf@notabene.neil.brown.name>
On Wed, Feb 14, 2018 at 12:15:06PM +1100, NeilBrown wrote:
>
> The interface for flushing the sunrpc auth cache was poorly
> designed and has caused problems a number of times.
>
> The design is that you write a timestamp, and all entries
> created before that time are discarded.
> The most obvious problem is that this is not what people
> actually want. They want to just flush the whole cache.
> The 1-second granularity can be a problem, as can the use
> of wall-clock time.
>
> A current problem is that code will write the current time to
> this file - expecting it to clear everything - and if the
> seconds number ticks over before this timestamp is checked,
> the test "then >= now" fails, and a full flush isn't forced.
>
> So lets just drop the subtleties and always flush the whole
> cache. The worst this could do is impose an extra cost
> refilling it, but that would require someone to be using
> non-standard tools.
>
> We still report an error if the string written is not a number,
> but we cause any valid number to flush the whole cache.
Thanks, applying for 4.17 (unless someone thinks it's more urgent).
--b.
>
> Reported-by: "Wang, Alan 1. (NSB - CN/Hangzhou)" <alan.1.wang@nokia-sbell.com>
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
> net/sunrpc/cache.c | 32 ++++++++++++++++----------------
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> index 8a7e1c774f9c..26582e27be6a 100644
> --- a/net/sunrpc/cache.c
> +++ b/net/sunrpc/cache.c
> @@ -1450,8 +1450,8 @@ static ssize_t write_flush(struct file *file, const char __user *buf,
> struct cache_detail *cd)
> {
> char tbuf[20];
> - char *bp, *ep;
> - time_t then, now;
> + char *ep;
> + time_t now;
>
> if (*ppos || count > sizeof(tbuf)-1)
> return -EINVAL;
> @@ -1461,24 +1461,24 @@ static ssize_t write_flush(struct file *file, const char __user *buf,
> simple_strtoul(tbuf, &ep, 0);
> if (*ep && *ep != '\n')
> return -EINVAL;
> + /* Note that while we check that 'buf' holds a valid number,
> + * we always ignore the value and just flush everything.
> + * Making use of the number leads to races.
> + */
>
> - bp = tbuf;
> - then = get_expiry(&bp);
> now = seconds_since_boot();
> - cd->nextcheck = now;
> - /* Can only set flush_time to 1 second beyond "now", or
> - * possibly 1 second beyond flushtime. This is because
> - * flush_time never goes backwards so it mustn't get too far
> - * ahead of time.
> + /* Always flush everything, so behave like cache_purge()
> + * Do this by advancing flush_time to the current time,
> + * or by one second if it has already reached the current time.
> + * Newly added cache entries will always have ->last_refresh greater
> + * that ->flush_time, so they don't get flushed prematurely.
> */
> - if (then >= now) {
> - /* Want to flush everything, so behave like cache_purge() */
> - if (cd->flush_time >= now)
> - now = cd->flush_time + 1;
> - then = now;
> - }
>
> - cd->flush_time = then;
> + if (cd->flush_time >= now)
> + now = cd->flush_time + 1;
> +
> + cd->flush_time = now;
> + cd->nextcheck = now;
> cache_flush();
>
> *ppos += count;
> --
> 2.14.0.rc0.dirty
>
prev parent reply other threads:[~2018-02-22 0:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-11 6:55 A special case in write_flush which cause the umount busy Wang, Alan 1. (NSB - CN/Hangzhou)
2018-02-13 19:57 ` NeilBrown
2018-02-13 21:03 ` J. Bruce Fields
2018-02-14 1:15 ` [PATCH] SUNRPC: cache: ignore timestamp written to 'flush' file NeilBrown
2018-02-22 0:46 ` J. Bruce Fields [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=20180222004652.GE6535@fieldses.org \
--to=bfields@fieldses.org \
--cc=alan.1.wang@nokia-sbell.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.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;
as well as URLs for NNTP newsgroup(s).