From: Peter Zijlstra <peterz@infradead.org>
To: Leo Yan <leo.yan@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Namhyung Kim <namhyung@kernel.org>,
Andi Kleen <ak@linux.intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] perf auxtrace: Optimize barriers with load-acquire and store-release
Date: Tue, 1 Jun 2021 08:58:35 +0200 [thread overview]
Message-ID: <YLXamz7BChYBspmY@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210601063342.GB10026@leoy-ThinkPad-X240s>
On Tue, Jun 01, 2021 at 02:33:42PM +0800, Leo Yan wrote:
>
> 32-bit perf wants to access 64-bit value atomically, I think it tries to
> avoid the issue caused by scenario:
>
> CPU0 (64-bit kernel) CPU1 (32-bit user)
>
> read head_lo
> WRITE_ONCE(head)
> read head_hi
Right; so I think Mark and me once spend a bunch of time on this for the
regular ring buffer, but my memory is vague.
It was supposed to be that the high word would always be zero on 32bit,
but it turns out that that is not in fact the case and we get to have
this race that's basically unfixable :/
Or maybe that was only the compat case.. Ah yes, so see the kernel uses
unsigned long, so on 32bit the high word is empty and we always
read/write 0s, unless you're explicitly doing daft things.
But on compat, the high word can be non-zero and we get to have 'fun'.
next prev parent reply other threads:[~2021-06-01 6:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 14:03 [PATCH v1 1/2] perf auxtrace: Change to use SMP memory barriers Leo Yan
2021-05-19 14:03 ` [PATCH v1 2/2] perf auxtrace: Optimize barriers with load-acquire and store-release Leo Yan
2021-05-31 15:10 ` Leo Yan
2021-05-31 15:55 ` Peter Zijlstra
2021-05-31 19:03 ` Adrian Hunter
2021-06-01 6:33 ` Leo Yan
2021-06-01 6:58 ` Peter Zijlstra [this message]
2021-06-01 9:07 ` Adrian Hunter
2021-06-01 9:17 ` Peter Zijlstra
2021-06-01 9:45 ` Adrian Hunter
2021-06-01 9:48 ` Peter Zijlstra
2021-06-01 14:56 ` Leo Yan
2021-06-01 6:48 ` Peter Zijlstra
2021-05-27 7:54 ` [PATCH v1 1/2] perf auxtrace: Change to use SMP memory barriers Adrian Hunter
2021-05-27 8:11 ` Peter Zijlstra
2021-05-27 8:25 ` Adrian Hunter
2021-05-27 9:24 ` Adrian Hunter
2021-05-27 9:57 ` Peter Zijlstra
2021-05-31 14:53 ` Leo Yan
2021-05-31 15:48 ` Peter Zijlstra
2021-06-01 3:21 ` Leo Yan
2021-05-27 9:45 ` Peter Zijlstra
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=YLXamz7BChYBspmY@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.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