Re: [PATCH] perf bench numa: Fix for loop in do_work

From: James Clark
Date: Thu Mar 30 2023 - 04:32:37 EST




On 30/03/2023 08:42, Andreas Herrmann wrote:
> j is of type int and start/end are of type long. Thus j might become
> negative and cause segfault in access_data(). Fix it by using long for
> j as well.
>
> Signed-off-by: Andreas Herrmann <aherrmann@xxxxxxx>
> ---
> tools/perf/bench/numa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Example of segfault (with 6.3.0-rc4) is:
>
> # ./perf bench numa mem -d -m -p 2 -t 12 -P 25425
> ...
> threads initialized in 6.052135 seconds.
> #
> perf: bench/numa.c:1654: __bench_numa: Assertion `!(!(((wait_stat) & 0x7f) == 0))' failed.
> Aborted (core dumped)
> # dmesg | grep segfault
> [78812.711311] thread 1/3[43215]: segfault at 7f07936c9ec0 ip 00000000004ab6d0 sp 00007f0acb1f9cb0 error 4
> [78812.711309] thread 1/9[43221]: segfault at 7f08bda71a70 ip 00000000004ab6d0 sp 00007f0ac81f3cb0 error 4
> [78812.711316] thread 1/4[43216]: segfault at 7f07ccf76a08 ip 00000000004ab6d0 sp 00007f0aca9f8cb0 error 4
> [78812.711325] thread 1/2[43214]: segfault at 7f08be2f44b0 ip 00000000004ab6d0 sp 00007f0acb9facb0 error 4
> [78812.711328] thread 1/8[43220]: segfault at 7f06d3096b20 ip 00000000004ab6d0 sp 00007f0ac89f4cb0 error 4
> [78812.711345] thread 1/6[43218]: segfault at 7f0774b46a18 ip 00000000004ab6d0 sp 00007f0ac99f6cb0 error 4 in perf[400000+caa000] likely on CPU 6 (core 8, socket 0)
> [78812.711366] thread 0/0[43224]: segfault at 7f08a936b130 ip 00000000004ab6d0 sp 00007f0acc9fccb0 error 4 in perf[400000+caa000] likely on CPU 1 (core 1, socket 0)
>
> diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
> index 9717c6c17433..1fbd7c947abc 100644
> --- a/tools/perf/bench/numa.c
> +++ b/tools/perf/bench/numa.c
> @@ -847,7 +847,7 @@ static u64 do_work(u8 *__data, long bytes, int nr, int nr_max, int loop, u64 val
>
> if (g->p.data_rand_walk) {
> u32 lfsr = nr + loop + val;
> - int j;
> + long j;
>
> for (i = 0; i < words/1024; i++) {
> long start, end;

Reviewed-by: James Clark <james.clark@xxxxxxx>