From: Dominique Martinet <asmadeus@codewreck.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: v9fs-developer@lists.sourceforge.net,
Latchesar Ionkov <lucho@ionkov.net>,
Eric Van Hensbergen <ericvh@gmail.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Ron Minnich <rminnich@sandia.gov>
Subject: Re: [V9fs-developer] [PATCH 4/6] 9p: Remove an unnecessary memory barrier
Date: Thu, 28 Jun 2018 15:40:29 +0200 [thread overview]
Message-ID: <20180628134029.GA24673@nautica> (raw)
In-Reply-To: <20180628132629.3148-5-willy@infradead.org>
Matthew Wilcox wrote on Thu, Jun 28, 2018:
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -436,13 +436,9 @@ void p9_client_cb(struct p9_client *c, struct p9_req_t *req, int status)
> {
> p9_debug(P9_DEBUG_MUX, " tag %d\n", req->tc->tag);
>
> - /*
> - * This barrier is needed to make sure any change made to req before
> - * the other thread wakes up will indeed be seen by the waiting side.
> - */
> - smp_wmb();
> req->status = status;
>
> + /* wake_up is an implicit write memory barrier */
Nope.
Please note the wmb is _before_ setting status, basically it protects
from cpu optimizations where status could be set before other fields,
then other core opportunistically checking and finding status is good so
other thread continuing.
I could only reproduce this bug with infiniband network, but it is very
definitely needed. Here is the commit message of when I added that barrier:
-----
9P: Add memory barriers to protect request fields over cb/rpc threads handoff
We need barriers to guarantee this pattern works as intended:
[w] req->rc, 1 [r] req->status, 1
wmb rmb
[w] req->status, 1 [r] req->rc
Where the wmb ensures that rc gets written before status,
and the rmb ensures that if you observe status == 1, rc is the new value.
-----
It might need an update to the comment though, if you thought about
removing it...
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2018-06-28 13:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-28 13:26 [PATCH 0/6] 9p: Use IDRs more effectively Matthew Wilcox
2018-06-28 13:26 ` [PATCH 1/6] 9p: Change p9_fid_create calling convention Matthew Wilcox
2018-06-28 13:26 ` [PATCH 2/6] 9p: Replace the fidlist with an IDR Matthew Wilcox
2018-07-11 12:40 ` [V9fs-developer] " Dominique Martinet
2018-07-11 12:52 ` Matthew Wilcox
2018-07-11 12:58 ` Dominique Martinet
2018-07-11 13:08 ` Matthew Wilcox
2018-06-28 13:26 ` [PATCH 3/6] 9p: Embed wait_queue_head into p9_req_t Matthew Wilcox
2018-06-28 13:26 ` [PATCH 4/6] 9p: Remove an unnecessary memory barrier Matthew Wilcox
2018-06-28 13:40 ` Dominique Martinet [this message]
2018-06-28 14:03 ` [V9fs-developer] " Matthew Wilcox
2018-06-28 14:33 ` Dominique Martinet
2018-06-28 13:26 ` [PATCH 5/6] 9p: Use a slab for allocating requests Matthew Wilcox
2018-07-11 13:33 ` [V9fs-developer] " Dominique Martinet
2018-07-11 14:13 ` Matthew Wilcox
2018-07-11 14:24 ` Dominique Martinet
2018-06-28 13:26 ` [PATCH 6/6] 9p: Remove p9_idpool Matthew Wilcox
2018-07-11 13:38 ` [V9fs-developer] [PATCH 0/6] 9p: Use IDRs more effectively Dominique Martinet
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=20180628134029.GA24673@nautica \
--to=asmadeus@codewreck.org \
--cc=ericvh@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=rminnich@sandia.gov \
--cc=v9fs-developer@lists.sourceforge.net \
--cc=willy@infradead.org \
/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).