Em Thu, Jan 09, 2020 at 10:46:11PM +0100, Jiri Olsa escreveu:
On Thu, Jan 09, 2020 at 09:00:41AM -0800, Andres Freund wrote:
SNIP
tools/perf/builtin-c2c.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c index e69f44941aad..f2e9d2b1b913 100644 --- a/tools/perf/builtin-c2c.c +++ b/tools/perf/builtin-c2c.c @@ -595,8 +595,8 @@ tot_hitm_cmp(struct perf_hpp_fmt *fmt __maybe_unused, { struct c2c_hist_entry *c2c_left; struct c2c_hist_entry *c2c_right;
- unsigned int tot_hitm_left;
- unsigned int tot_hitm_right;
- uint64_t tot_hitm_left;
- uint64_t tot_hitm_right;
that change looks right, but I can't see how that could happened because of change in Fixes: tag
was the return statement of this function:
return tot_hitm_left - tot_hitm_right;considered to be 'unsigned int' and then converted to int64_t, which would treat negative 'unsigned int' as big positive 'int64_t'?
Correct. So e.g. when comparing 1 and 2 tot_hitm, we'd get (int64_t) UINT_MAX as a result, which is obviously wrong. However, due to hist_entry__sort() returning int at the time, this was masked, as the int64_t was cast to int. Thereby again yielding a negative number for the comparisons of hist_entry__sort()'s result. After hist_entry__sort() was fixed however, there never could be negative return values (but 0's are possible) of hist_entry__sort() for c2c.
I see.. ok
Acked-by: Jiri Olsa jolsa@redhat.com
Thanks, applied.
- Arnaldo