Re: [PATCH 4/4] perf test: Add false_sharing workload exhibiting cross-CPU false sharing

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf test: stack buffer overflow in false_sharing via CPU_SET(-1)
--

commit ca3d54512dd3bcec14cdfc83ca90f31bcb2e15f0
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf test: Add false_sharing workload exhibiting cross-CPU false sharing
    
Add a 'perf test -w false_sharing' workload that hammers one shared
struct from several CPUs, shaped as a TCP connection. The packet path
runs in the main thread and up to four lookup threads hash the
five-tuple and pull the config.

> diff --git a/tools/perf/tests/workloads/false_sharing.c b/tools/perf/tests/workloads/false_sharing.c
> new file mode 100644
> index 0000000000000..6fccb81e3ed1c
> --- /dev/null
> +++ b/tools/perf/tests/workloads/false_sharing.c
[ ... ]
> +static void pin_to_cpu(int cpu)
> +{
> +	cpu_set_t set;
> +
> +	CPU_ZERO(&set);
> +	CPU_SET(cpu, &set);

[Severity: Medium]
When false_sharing() runs on a single-core machine or a restricted cpuset
(where nallowed <= 1), it assigns -1 to the reader thread's target CPU:

false_sharing() {
    ...
    for (i = 0; i < nreaders; i++) {
        int cpu = nallowed > 1 ? allowed[(i + 1) % nallowed] : -1;
        readers[i].cpu = cpu;
        ...
    }
}

Unlike the writer thread, which correctly guards the call with
if (writer_cpu >= 0), the reader thread unconditionally calls pin_to_cpu(-1):

reader_fn() {
    ...
    pin_to_cpu(r->cpu);
    ...
}

This passes -1 directly to CPU_SET() without any bounds checking. Could this
negative index result in an out-of-bounds stack write that corrupts memory?

> +	/* Best effort: in a restricted cpuset this fails and the thread runs unpinned. */
> +	pthread_setaffinity_np(pthread_self(), sizeof(set), &set);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928162250.2413383-1-acme@kernel.org?part=4