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: A special case in write_flush which cause the umount busy
Date: Tue, 13 Feb 2018 16:03:14 -0500 [thread overview]
Message-ID: <20180213210314.GA12201@fieldses.org> (raw)
In-Reply-To: <87inb0r7cd.fsf@notabene.neil.brown.name>
On Wed, Feb 14, 2018 at 06:57:06AM +1100, NeilBrown wrote:
> I think this change is safe. It is a bit of a hack, but the "flush"
> interface was actually very poorly designed and I don't think it *can*
> be implemented cleanly.
> Maybe we should just ignore the number written in and *always* flush
> the cache completely. That is was it always wanted.
>
> See below.
>
> Bruce: do you have any thoughts on this?
I'm fine with ignoring the number--I agree that the chance anyone is
doing anything fancier is vanishingly small.
--b.
>
> Thanks,
> NeilBrown
>
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> index aa36dad32db1..43f117d1547e 100644
> --- a/net/sunrpc/cache.c
> +++ b/net/sunrpc/cache.c
> @@ -1450,7 +1450,7 @@ static ssize_t write_flush(struct file *file, const char __user *buf,
> struct cache_detail *cd)
> {
> char tbuf[20];
> - char *bp, *ep;
> + char *ep;
> time_t then, now;
>
> if (*ppos || count > sizeof(tbuf)-1)
> @@ -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
> + /* Always flush everything, so behave like cache_purge()
> + * 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.
> */
> - 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;
>
>
> >
> > --------------------------------------------------------------------------
> > 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.
> > */
> > if (then != now)
> > printk("%s %d then = %d, now = %d\n", __func__, __LINE__, then, now);
> > - if (then >= now) {
> > + if (then >= now - 1) {
> > /* Want to flush eve
next prev parent reply other threads:[~2018-02-13 21:03 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 [this message]
2018-02-14 1:15 ` [PATCH] SUNRPC: cache: ignore timestamp written to 'flush' file NeilBrown
2018-02-22 0:46 ` J. Bruce Fields
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=20180213210314.GA12201@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).