From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
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: Tue, 6 Dec 2022 07:27:48 +0900 [thread overview]
Message-ID: <Y45wZEvO8gOanV85@codewreck.org> (raw)
In-Reply-To: <3368929.hG1Ktuj5m1@silver>
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 -- I think we're just protecting against compiler
reordering or if on some arch the store isn't actually atomic.
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.
--
Dominique
next prev parent reply other threads:[~2022-12-05 22:28 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 [this message]
2022-12-08 15:51 ` Christian Schoenebeck
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=Y45wZEvO8gOanV85@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=elver@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--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.