All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: William Dauchy <wdauchy@gmail.com>
Cc: NeilBrown <neilb@suse.com>,
	Linux NFS mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] sunrpc/cache: drop reference when sunrpc_cache_pipe_upcall() detects a race
Date: Wed, 16 Mar 2016 11:05:10 -0400	[thread overview]
Message-ID: <20160316150510.GE11520@fieldses.org> (raw)
In-Reply-To: <CAJ75kXaWqMSgjp4U=M5Jz7VUXt_yJTo31MTQV0fh1R1TV9_W7Q@mail.gmail.com>

On Wed, Mar 16, 2016 at 08:31:03AM +0100, William Dauchy wrote:
> Hi Bruce,
> 
> Thank you for your reply.
> 
> On Tue, Mar 15, 2016 at 9:37 PM, NeilBrown <neilb@suse.com> wrote:
> > I agree that it isn't needed for stable - the race is tiny and the
> > consequence of losing the race is that entries get stuck in the cache
> > and possible an exported filesystem cannot be unmounted.
> 
> I believe in an industrial usage, this race will become more common;

Why is that?

> moreover the consequence of an exported filesystem which can't be
> unmounted is not something I can accept in some environment.
> 
> I accept your judgment about including it or not in -stable but I am
> just complaining about the lack of further consideration for those
> type of fixes in nfs generally speaking. In an industrial usage, we
> are hitting races way more easily than in a normal usage; lost of them
> are already fixed and we do backports ourself.

Do you have a list?

> We are at a point where
> it becomes almost impossible to come with a proof and say "we are
> hitting this race, and this patch fixes the issue, please backport in
> -stable".

I don't expect *proof*, necessarily, but some sort of argument would be
helpful.

--b.

  reply	other threads:[~2016-03-16 15:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04  6:20 [PATCH] sunrpc/cache: drop reference when sunrpc_cache_pipe_upcall() detects a race NeilBrown
2016-03-14 20:38 ` J. Bruce Fields
2016-03-15 12:43   ` William Dauchy
2016-03-15 13:19     ` J. Bruce Fields
2016-03-15 20:37       ` NeilBrown
2016-03-16  7:31         ` William Dauchy
2016-03-16 15:05           ` J. Bruce Fields [this message]
2016-03-16 15:38             ` William Dauchy
2016-03-16 16:00               ` J. Bruce Fields
2016-03-16 16:16                 ` William Dauchy
2016-03-18  6:05               ` NeilBrown

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=20160316150510.GE11520@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=wdauchy@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 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.