From: sashiko-bot@kernel.org
To: "Aaron Tomlin" <atomlin@atomlin.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [RFC PATCH] perf sched latency: Add histogram and time interval options
Date: Fri, 24 Jul 2026 20:22:05 +0000 [thread overview]
Message-ID: <20260724202205.D33811F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724201207.661300-1-atomlin@atomlin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Integer overflow in linear histogram bucket calculation allows out-of-bounds array writes.
--
--- Patch [1]: [RFC PATCH] perf sched latency: Add histogram and time interval options ---
commit 94bdb73befc369d9beaf56650ada8fcf80ad4ac5
Author: Aaron Tomlin <atomlin@atomlin.com>
perf sched latency: Add histogram and time interval options
This patch introduces options to display a latency histogram in perf sched
latency. It includes both logarithmic and linear bucketing modes, as well
as a time interval filter.
> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
> --- a/tools/perf/builtin-sched.c
> +++ b/tools/perf/builtin-sched.c
[ ... ]
> @@ -246,6 +313,59 @@ struct perf_sched {
> struct perf_data *data;
> };
>
> +static int latency_bucket(struct perf_sched *sched, u64 delta_ns)
> +{
> + u64 delta_us = delta_ns / NSEC_PER_USEC;
> + int b;
> +
> + if (sched->hist_mode == HIST_MODE_LINEAR) {
> + b = delta_us / 100;
[Severity: Medium]
Could a very large delta_us value cause an integer overflow here?
If perf.data contains a massive time difference between wakeup and sched-in,
delta_us / 100 could exceed INT_MAX. Since b is a signed 32-bit integer,
this would cause b to wrap into a negative number.
> + } else {
> + if (delta_us == 0)
> + return 0;
> + b = 64 - __builtin_clzll(delta_us);
> + }
> +
> + if (b >= NUM_LAT_BUCKETS - 1)
Because b is signed, this bounds check will evaluate to false for negative
numbers, allowing a negative index to be returned.
> + return NUM_LAT_BUCKETS - 1;
> + return b;
> +}
[ ... ]
> @@ -1129,10 +1249,12 @@ add_runtime_event(struct work_atoms *atoms, u64 delta,
> }
>
> static void
> -add_sched_in_event(struct work_atoms *atoms, u64 timestamp)
> +add_sched_in_event(struct perf_sched *sched, struct work_atoms *atoms,
> + u64 timestamp)
> {
> struct work_atom *atom;
> u64 delta;
> + int b;
>
> if (list_empty(&atoms->work_list))
> return;
> @@ -1158,6 +1280,10 @@ add_sched_in_event(struct work_atoms *atoms, u64 timestamp)
> atoms->max_lat_end = timestamp;
> }
> atoms->nb_atoms++;
> +
> + b = latency_bucket(sched, delta);
> + atoms->hist[b]++;
> + sched->global_hist[b]++;
If latency_bucket() returns a negative value, does this result in an
out-of-bounds memory write that could corrupt memory before these arrays?
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260724201207.661300-1-atomlin@atomlin.com?part=1
next prev parent reply other threads:[~2026-07-24 20:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 20:12 [RFC PATCH] perf sched latency: Add histogram and time interval options Aaron Tomlin
2026-07-24 20:22 ` sashiko-bot [this message]
2026-07-24 23:27 ` Ian Rogers
2026-07-25 3:10 ` Aaron Tomlin
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=20260724202205.D33811F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=atomlin@atomlin.com \
--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 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.