From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71524C7EE23 for ; Tue, 23 May 2023 17:04:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237842AbjEWREc (ORCPT ); Tue, 23 May 2023 13:04:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237921AbjEWREb (ORCPT ); Tue, 23 May 2023 13:04:31 -0400 Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C3DDDD for ; Tue, 23 May 2023 10:04:27 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id e9e14a558f8ab-335d6260e9bso169995ab.1 for ; Tue, 23 May 2023 10:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684861467; x=1687453467; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=muALjIcfvVCb2tAeAMgrB1kx2WpHTC3GVkLoOVcMWrs=; b=hPYTWkjDJ0qxhJWHGuhyTTZRm+3Lq/ZZ6L2qVorxEtDJ2W0UwUoGB1FjZI548qw1Ty MaDNYFql4e4vWR1A6Lb3Ctu2SPMnaoAnHh2Cgdr2x1V6IHPOBydyRqclUFrAuIPDxMCZ R2vzfht1bM4Y2Ny8bdBYdO/pRLDNf1Ls9mi4rwsuFYI/LtZwmBOpPFlwKPFzmEOEUPve G9jwB/AyYTW5EI7x993RqKRFR1EIH58caym0JR77CvtWA6OK147um1EKkJp9Sv2t87qG HaXaIiPzdNH2VlGOw+uyHeKaIHRvewzvryOrTLGFknKJqgpS0S40r5HTuO9KnWMTNPkA sKfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684861467; x=1687453467; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=muALjIcfvVCb2tAeAMgrB1kx2WpHTC3GVkLoOVcMWrs=; b=GtIrVN+OycmKwH0HyOuZtHrY6qAlSB8NaZUPUlQQyB3LNyg8vZvvb7gLNQIDvszujT RMCy7mYoUS4ZvCYCNhMTsSYEPnWct8OBozQtknJYuvjfJaRQVrbr84grOsdAmCosfFzg 0wuHFKD4UqhZ4066BCUSwq9D7dpttSKl3VwbL8duTsP35GevFq8p7NF7l/6wVD+2dN9B rwjzFMAjKwjSHU63KQLhTn05/L1B/OgROMghgYZwUdjQh7FqD+diYiE87JCctZOYBWs+ rF/xA+fZTNV4bVdY8ZSJ9h74TqGXeQGxyS7FMgX+LBK2vKWiWoq5Ct5GUagAwoUtbQLF RIRg== X-Gm-Message-State: AC+VfDyvmD+gczXHlqQcHyyonEn+XxpCV9z+zIuk6+KbZQ38ojFuv3el mDEtX/v/jIA0IkCYVvaYFP9tDKMp6dmNhkfPkkBm0g== X-Google-Smtp-Source: ACHHUZ68eb454ZJ7+cyvvL1swgmhHWaWazGxR2m8pCubno25/gamawQfw4hRdQzBzt1f0a/HDJWu+8I248pEUTug6+A= X-Received: by 2002:a05:6e02:190f:b0:335:12d6:2c7d with SMTP id w15-20020a056e02190f00b0033512d62c7dmr12122ilu.0.1684861466749; Tue, 23 May 2023 10:04:26 -0700 (PDT) MIME-Version: 1.0 References: <20230523044446.1020769-1-irogers@google.com> <20230523044446.1020769-2-irogers@google.com> <0a325fc8-2945-862a-e6bd-eb7b0ac46fe5@intel.com> In-Reply-To: <0a325fc8-2945-862a-e6bd-eb7b0ac46fe5@intel.com> From: Ian Rogers Date: Tue, 23 May 2023 10:04:15 -0700 Message-ID: Subject: Re: [PATCH v1 2/2] perf evsel: for_each_group fixes To: Adrian Hunter Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Kan Liang , Sandipan Das , James Clark , Dmitrii Dolgov <9erthalion6@gmail.com>, Changbin Du , Rob Herring , Xing Zhengjun , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-perf-users@vger.kernel.org On Tue, May 23, 2023 at 7:33=E2=80=AFAM Adrian Hunter wrote: > > On 23/05/23 07:44, Ian Rogers wrote: > > Address/memory sanitizer was reporting issues in evsel__group_pmu_name > > because the for_each_group_evsel loop didn't terminate when the head > > was reached, the head would then be cast and accessed as an evsel > > leading to invalid memory accesses. Fix for_each_group_member and > > for_each_group_evsel to terminate at the list head. Note, > > evsel__group_pmu_name no longer iterates the group, but the problem is > > present regardless. > > > > Fixes: 717e263fc354 ("perf report: Show group description when event gr= oup is enabled") > > Signed-off-by: Ian Rogers > > --- > > tools/perf/util/evsel.h | 24 ++++++++++++++++-------- > > tools/perf/util/evsel_fprintf.c | 1 + > > 2 files changed, 17 insertions(+), 8 deletions(-) > > > > diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h > > index 820771a649b2..6a64543c7612 100644 > > --- a/tools/perf/util/evsel.h > > +++ b/tools/perf/util/evsel.h > > @@ -462,16 +462,24 @@ static inline int evsel__group_idx(struct evsel *= evsel) > > } > > > > /* Iterates group WITHOUT the leader. */ > > -#define for_each_group_member(_evsel, _leader) = \ > > -for ((_evsel) =3D list_entry((_leader)->core.node.next, struct evsel, = core.node); \ > > - (_evsel) && (_evsel)->core.leader =3D=3D (&_leader->core); = \ > > - (_evsel) =3D list_entry((_evsel)->core.node.next, struct evsel, c= ore.node)) > > +#define for_each_group_member_head(_evsel, _leader, _head) = \ > > +for ((_evsel) =3D list_entry((_leader)->core.node.next, struct evsel, = core.node); \ > > + (_evsel) && (&(_evsel)->core.node !=3D (_head)) && = \ > > Extra parentheses perhaps not needed e.g. just > > &(_evsel)->core.node !=3D (_head) > > > + (_evsel)->core.leader =3D=3D (&_leader->core); = \ > > Parentheses look odd, maybe should be: > > &(_leader)->core > > > + (_evsel) =3D list_entry((_evsel)->core.node.next, struct evsel, c= ore.node)) > > + > > +#define for_each_group_member(_evsel, _leader) = \ > > + for_each_group_member_head(_evsel, _leader, &(_leader)->evlist->c= ore.entries) > > Did you consider using (_leader)->core.nr_members so that it is not > necessary to assume the evlist back pointer is populated. Thanks! I'll address the other comments in v2. Wrt nr_members/evsel->evlist, I think we can use it to avoid the whole list scan in evsel__compute_group_pmu_name. We could use it here but in all the non-parse_events__sort_events_and_fix_groups cases we have the evsel->evlist and testing for the list head seems more consistent with other list_for_each cases. Thanks, Ian > > > > /* Iterates group WITH the leader. */ > > -#define for_each_group_evsel(_evsel, _leader) = \ > > -for ((_evsel) =3D _leader; = \ > > - (_evsel) && (_evsel)->core.leader =3D=3D (&_leader->core); = \ > > - (_evsel) =3D list_entry((_evsel)->core.node.next, struct evsel, c= ore.node)) > > +#define for_each_group_evsel_head(_evsel, _leader, _head) = \ > > +for ((_evsel) =3D _leader; = \ > > + (_evsel) && (&(_evsel)->core.node !=3D (_head)) && = \ > > + (_evsel)->core.leader =3D=3D (&_leader->core); = \ > > + (_evsel) =3D list_entry((_evsel)->core.node.next, struct evsel, c= ore.node)) > > + > > +#define for_each_group_evsel(_evsel, _leader) = \ > > + for_each_group_evsel_head(_evsel, _leader, &(_leader)->evlist->co= re.entries) > > > > static inline bool evsel__has_branch_callstack(const struct evsel *evs= el) > > { > > diff --git a/tools/perf/util/evsel_fprintf.c b/tools/perf/util/evsel_fp= rintf.c > > index cc80ec554c0a..036a2171dc1c 100644 > > --- a/tools/perf/util/evsel_fprintf.c > > +++ b/tools/perf/util/evsel_fprintf.c > > @@ -2,6 +2,7 @@ > > #include > > #include > > #include > > +#include "util/evlist.h" > > #include "evsel.h" > > #include "util/evsel_fprintf.h" > > #include "util/event.h" >