From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Dominique Martinet <asmadeus@codewreck.org>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Marco Elver <elver@google.com>
Subject: Re: [PATCH] 9p/client: fix data race on req->status
Date: Thu, 08 Dec 2022 16:51:27 +0100 [thread overview]
Message-ID: <167052961.MU3OA6Uzks@silver> (raw)
In-Reply-To: <Y45wZEvO8gOanV85@codewreck.org>
On Monday, December 5, 2022 11:27:48 PM CET Dominique Martinet wrote:
> Christian Schoenebeck wrote on Mon, Dec 05, 2022 at 04:19:01PM +0100:
> > I must have missed the prior discussion, but looking at the suggested
>
> Good point, I'll add a link to the report as well...
> It's this thread:
> https://lkml.kernel.org/r/CA+G9fYsK5WUxs6p9NaE4e3p7ew_+s0SdW0+FnBgiLWdYYOvoMg@mail.gmail.com
>
> > solution: if there is no lock, then adding READ_ONCE() and WRITE_ONCE() would
> > not fix cross-CPU issues, as those would not have a memory barrier in that
> > case.
> >
> > Shouldn't that therefore rather be at least smp_load_acquire() and
> > smp_store_release() at such places instead?
>
> The barrier is here --
Right, looks like most of it should be fine. Maybe p9_client_zc_rpc() needs a
barrier as well?
> I think we're just protecting against compiler
> reordering or if on some arch the store isn't actually atomic.
And access order within the same thread.
> This code path actually was broken before I added the barrier a while
> ago (2b6e72ed747f68a03), as I was observing some rare but very real
> errors on a big server so I'm fairly confident that for at least x86_64
> the generated code isn't too bad, but if KCSAN helps catching stuff I
> won't complain.
What about p9_tag_alloc()?
next prev parent reply other threads:[~2022-12-08 15:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-05 12:47 [PATCH] 9p/client: fix data race on req->status Dominique Martinet
2022-12-05 13:06 ` Marco Elver
2022-12-05 15:19 ` Christian Schoenebeck
2022-12-05 22:27 ` Dominique Martinet
2022-12-08 15:51 ` Christian Schoenebeck [this message]
2022-12-08 23:50 ` Dominique Martinet
2022-12-09 13:45 ` Christian Schoenebeck
2022-12-09 21:12 ` Dominique Martinet
2022-12-12 13:39 ` Christian Schoenebeck
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=167052961.MU3OA6Uzks@silver \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=elver@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=v9fs-developer@lists.sourceforge.net \
/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.