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 12:00:17 -0400 [thread overview]
Message-ID: <20160316160017.GF11520@fieldses.org> (raw)
In-Reply-To: <CAJ75kXZkt1rqZ9e9gBC1Feywr9w7Cuqscgd+6yWU5oqOmQvU+Q@mail.gmail.com>
On Wed, Mar 16, 2016 at 04:38:55PM +0100, William Dauchy wrote:
> Hi Bruce,
>
> Thank your for your reply.
>
> On Wed, Mar 16, 2016 at 4:05 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > Why is that?
>
> It's indeed not really based on actual proof but based on the experience we had.
> Faced several bugs, and it appears we had less issues by backporting a
> few commits; e.g related to races, leaks, performances regressions. We
> did not spent enough time on it to actually show this commit was
> actually fixing an issue hit.
>
> > Do you have a list?
>
> I am currently trying to switch from v3.14 to v4.1 (nfs client). So
> even know it is off topic, those I have in mind:
> 0d2a970 SUNRPC: Fix a backchannel race
> 6851447 SUNRPC: Fix a backchannel deadlock
> 0993920 SUNRPC: Prevent SYN+SYNACK+RST storms
> 03c78827 SUNRPC: Fix races between socket connection and destroy code
> a41cbe8 Failing to send a CLOSE if file is opened WRONLY and server
> reboots on a 4.x mount
> 39d0d3b NFS: Fix a tracepoint NULL-pointer dereference
> 5e99b53 nfs4: reset states to use open_stateid when returning
> delegation voluntarily
> e92c1e0 NFSv4: Fix a nograce recovery hang
> 6b55970 nfs: Fix a memory leak when meeting an unsupported state protect
>
> I am probably wrong on most of them but we had better stability after
> applying them and I probably forgot some.
Note options 2 and 3 in Documentation/stable_kernel_rules.txt. You can
send a backport to stable@vger.kernel.org yourself. When you do so,
please cc: the relevant maintainers (looks like Trond and Anna for the
above) and linux-nfs@vger.kernel.org, so they can ACK/NACK.
> > I don't expect *proof*, necessarily, but some sort of argument would be
> > helpful.
>
> In my environment, if I hit this race, it is not acceptable to not
> being able to unmount the filesystem.
OK. I'd be interested in your use case if you get the chance.
--b.
next prev parent reply other threads:[~2016-03-16 16:00 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
2016-03-16 15:38 ` William Dauchy
2016-03-16 16:00 ` J. Bruce Fields [this message]
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=20160316160017.GF11520@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 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).