From: sashiko-bot@kernel.org
To: "James Clark" <james.clark@linaro.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 09/18] perf test: Add named_threads workload
Date: Tue, 02 Jun 2026 15:01:22 +0000 [thread overview]
Message-ID: <20260602150122.7F8BB1F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260602-james-cs-context-tracking-fix-v2-9-85b5ce6f55c6@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Signed integer overflow and data races in the test workload loop cause Undefined Behavior (UB), which triggers TSAN/UBSAN failures and allows the compiler to optimize the loop away.
--
commit 2c5615e29c7533d5597f41700af3d8e8f97a8e97
Author: James Clark <james.clark@linaro.org>
perf test: Add named_threads workload
This commit adds a workload that spawns multiple threads which run a unique
function performing a multiplication loop. Each thread sets its own name,
which is used to test that processor trace decoding handles concurrent
threads correctly.
> diff --git a/tools/perf/tests/workloads/named_threads.c b/tools/perf/tests/workloads/named_threads.c
> new file mode 100644
> index 0000000000000..dc8070a98df4c
> --- /dev/null
> +++ b/tools/perf/tests/workloads/named_threads.c
[ ... ]
> +static int iterations = 500;
> +int named_threads_work = 1234;
> +
> +typedef void *(*thread_fn_t)(void *);
> +
> +#define DEFINE_THREAD(n) \
> +noinline void *named_threads_thread##n(void *arg __maybe_unused) \
> +{ \
> + pthread_setname_np(pthread_self(), "thread" #n); \
> + for (int i = 0; i < iterations; i++) \
> + named_threads_work *= 3; \
[Severity: Medium]
Will this loop trigger undefined behavior due to signed integer overflow and
data races?
Because named_threads_work is a shared global signed integer modified
concurrently without synchronization, this creates a data race.
Furthermore, multiplying 1234 by 3 for 500 iterations will cause a signed
integer overflow after just 14 iterations.
Since both data races and signed integer overflow are undefined behavior,
could the compiler aggressively optimize this loop away entirely, defeating
the purpose of generating trace data for the processor trace test?
Would it be safer to use a thread-local variable or declare it as a
volatile unsigned int, similar to the leafloop workload, to prevent
sanitizer failures and ensure the work is actually simulated?
> + \
> + return NULL; \
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260602-james-cs-context-tracking-fix-v2-0-85b5ce6f55c6@linaro.org?part=9
next prev parent reply other threads:[~2026-06-02 15:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 14:26 [PATCH v2 00/18] perf cs-etm: Queue context packets for frontend James Clark
2026-06-02 14:26 ` [PATCH v2 01/18] " James Clark
2026-06-02 14:43 ` sashiko-bot
2026-06-02 14:26 ` [PATCH v2 02/18] perf test: Add workload-ctl option James Clark
2026-06-02 14:40 ` sashiko-bot
2026-06-02 14:26 ` [PATCH v2 03/18] perf test: Add a workload that forces context switches James Clark
2026-06-02 14:38 ` sashiko-bot
2026-06-02 14:26 ` [PATCH v2 04/18] perf test cs-etm: Test process attribution James Clark
2026-06-02 14:26 ` [PATCH v2 05/18] perf test: Add deterministic workload James Clark
2026-06-02 14:49 ` sashiko-bot
2026-06-02 14:26 ` [PATCH v2 06/18] perf test cs-etm: Replace unroll loop thread with deterministic decode test James Clark
2026-06-02 14:26 ` [PATCH v2 07/18] perf test cs-etm: Remove asm_pure_loop test James Clark
2026-06-02 14:26 ` [PATCH v2 08/18] perf test cs-etm: Replace memcpy test with raw dump stress test James Clark
2026-06-02 15:01 ` sashiko-bot
2026-06-02 14:26 ` [PATCH v2 09/18] perf test: Add named_threads workload James Clark
2026-06-02 15:01 ` sashiko-bot [this message]
2026-06-02 14:26 ` [PATCH v2 10/18] perf test cs-etm: Test decoding for concurrent threads test James Clark
2026-06-02 14:26 ` [PATCH v2 11/18] perf test cs-etm: Remove duplicate branch tests James Clark
2026-06-02 15:05 ` sashiko-bot
2026-06-02 14:26 ` [PATCH v2 12/18] perf test cs-etm: Reduce snapshot size James Clark
2026-06-02 14:26 ` [PATCH v2 13/18] perf test cs-etm: Speed up basic test James Clark
2026-06-02 14:26 ` [PATCH v2 14/18] perf test cs-etm: Remove unused Coresight workloads James Clark
2026-06-02 14:26 ` [PATCH v2 15/18] perf test cs-etm: Make disassembly test use kcore James Clark
2026-06-02 14:26 ` [PATCH v2 16/18] perf test cs-etm: Add all branch instructions to test James Clark
2026-06-02 14:26 ` [PATCH v2 17/18] perf test cs-etm: Speed up disassembly test James Clark
2026-06-02 15:26 ` sashiko-bot
2026-06-02 14:27 ` [PATCH v2 18/18] perf test cs-etm: Move existing tests to coresight folder James Clark
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=20260602150122.7F8BB1F00898@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=james.clark@linaro.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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