Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 19 Aug 2022 14:28:56 -0300
From:   Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To:     Ian Rogers <irogers@google.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        James Clark <james.clark@arm.com>,
        Kees Cook <keescook@chromium.org>,
        "Gustavo A. R. Silva" <gustavoars@kernel.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Riccardo Mancini <rickyman7@gmail.com>,
        German Gomez <german.gomez@arm.com>,
        Colin Ian King <colin.king@intel.com>,
        Song Liu <songliubraving@fb.com>,
        Dave Marchevsky <davemarchevsky@fb.com>,
        Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
        Alexey Bayduraev <alexey.v.bayduraev@linux.intel.com>,
        Leo Yan <leo.yan@linaro.org>, linux-perf-users@vger.kernel.org,
        linux-kernel@vger.kernel.org, Stephane Eranian <eranian@google.com>
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2_4/6=5D_perf_cpumap=3A_Fix_?= =?US-ASCII?Q?alignment_for_masks_in_event_encoding?=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAP-5=fWi5KaV40jcC1ZGfTAJ+bc52ueMvd0yREUHxSYk7y1MNw@mail.gmail.com>
References: <20220614143353.1559597-1-irogers@google.com> <20220614143353.1559597-5-irogers@google.com> <Yv60COAP90TEiWkx@kernel.org> <Yv+zK8UxUAP83zkp@kernel.org> <CAP-5=fWi5KaV40jcC1ZGfTAJ+bc52ueMvd0yREUHxSYk7y1MNw@mail.gmail.com>
Message-ID: <4381FF21-053E-4089-A030-F9CD84C87AD5@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On August 19, 2022 2:09:09 PM GMT-03:00, Ian Rogers <irogers@google=2Ecom>=
 wrote:
>On Fri, Aug 19, 2022 at 8:58 AM Arnaldo Carvalho de Melo
><acme@kernel=2Eorg> wrote:
>>
>> Em Thu, Aug 18, 2022 at 06:50:00PM -0300, Arnaldo Carvalho de Melo escr=
eveu:
>> > Em Tue, Jun 14, 2022 at 07:33:51AM -0700, Ian Rogers escreveu:
>> > > A mask encoding of a cpu map is laid out as:
>> > >   u16 nr
>> > >   u16 long_size
>> > >   unsigned long mask[];
>> > > However, the mask may be 8-byte aligned meaning there is a 4-byte p=
ad
>> > > after long_size=2E This means 32-bit and 64-bit builds see the mask=
 as
>> > > being at different offsets=2E On top of this the structure is in th=
e byte
>> > > data[] encoded as:
>> > >   u16 type
>> > >   char data[]
>> > > This means the mask's struct isn't the required 4 or 8 byte aligned=
, but
>> > > is offset by 2=2E Consequently the long reads and writes are causin=
g
>> > > undefined behavior as the alignment is broken=2E
>> > >
>> > > Fix the mask struct by creating explicit 32 and 64-bit variants, us=
e a
>> > > union to avoid data[] and casts; the struct must be packed so the
>> > > layout matches the existing perf=2Edata layout=2E Taking an address=
 of a
>> > > member of a packed struct breaks alignment so pass the packed
>> > > perf_record_cpu_map_data to functions, so they can access variables=
 with
>> > > the right alignment=2E
>> > >
>> > > As the 64-bit version has 4 bytes of padding, optimizing writing to=
 only
>> > > write the 32-bit version=2E
>> > >
>> > > Signed-off-by: Ian Rogers <irogers@google=2Ecom>
>> > > ---
>> > >  tools/lib/perf/include/perf/event=2Eh | 36 +++++++++++--
>> > >  tools/perf/tests/cpumap=2Ec           | 19 ++++---
>> > >  tools/perf/util/cpumap=2Ec            | 80 +++++++++++++++++++++++=
------
>> > >  tools/perf/util/cpumap=2Eh            |  4 +-
>> > >  tools/perf/util/session=2Ec           | 30 +++++------
>> > >  tools/perf/util/synthetic-events=2Ec  | 34 +++++++-----
>> > >  6 files changed, 143 insertions(+), 60 deletions(-)
>> > >
>> > > diff --git a/tools/lib/perf/include/perf/event=2Eh b/tools/lib/perf=
/include/perf/event=2Eh
>> > > index e7758707cadd=2E=2Ed2d32589758a 100644
>> > > --- a/tools/lib/perf/include/perf/event=2Eh
>> > > +++ b/tools/lib/perf/include/perf/event=2Eh
>> > > @@ -6,6 +6,7 @@
>> > >  #include <linux/types=2Eh>
>> > >  #include <linux/limits=2Eh>
>> > >  #include <linux/bpf=2Eh>
>> > > +#include <linux/compiler=2Eh>
>> > >  #include <sys/types=2Eh> /* pid_t */
>> > >
>> > >  #define event_contains(obj, mem) ((obj)=2Eheader=2Esize > offsetof=
(typeof(obj), mem))
>> > > @@ -153,20 +154,47 @@ enum {
>> > >     PERF_CPU_MAP__MASK =3D 1,
>> > >  };
>> > >
>> > > +/*
>> > > + * Array encoding of a perf_cpu_map where nr is the number of entr=
ies in cpu[]
>> > > + * and each entry is a value for a CPU in the map=2E
>> > > + */
>> > >  struct cpu_map_entries {
>> > >     __u16                    nr;
>> > >     __u16                    cpu[];
>> > >  };
>> > >
>> > > -struct perf_record_record_cpu_map {
>> > > +/* Bitmap encoding of a perf_cpu_map where bitmap entries are 32-b=
it=2E */
>> > > +struct perf_record_mask_cpu_map32 {
>> > > +   /* Number of mask values=2E */
>> > >     __u16                    nr;
>> > > +   /* Constant 4=2E */
>> > >     __u16                    long_size;
>> > > -   unsigned long            mask[];
>> > > +   /* Bitmap data=2E */
>> > > +   __u32                    mask[];
>> > >  };
>> > >
>> > > -struct perf_record_cpu_map_data {
>> > > +/* Bitmap encoding of a perf_cpu_map where bitmap entries are 64-b=
it=2E */
>> > > +struct perf_record_mask_cpu_map64 {
>> > > +   /* Number of mask values=2E */
>> > > +   __u16                    nr;
>> > > +   /* Constant 8=2E */
>> > > +   __u16                    long_size;
>> > > +   /* Legacy padding=2E */
>> > > +   char                     __pad[4];
>> > > +   /* Bitmap data=2E */
>> > > +   __u64                    mask[];
>> > > +};
>> > > +
>> > > +struct __packed perf_record_cpu_map_data {
>> >
>> > In various places I'm getting this:
>> >
>> > [perfbuilder@five x-riscv]$ export BUILD_TARBALL=3Dhttp://192=2E168=
=2E86=2E14/perf/perf-6=2E0=2E0-rc1=2Etar=2Exz
>> > [perfbuilder@five x-riscv]$ time dm =2E
>> >    1     5=2E47 ubuntu:22=2E04-x-riscv64        : FAIL gcc version 11=
=2E2=2E0 (Ubuntu 11=2E2=2E0-16ubuntu1)
>> >     In file included from mmap=2Ec:10:
>> >     /git/perf-6=2E0=2E0-rc1/tools/lib/perf/include/perf/event=2Eh:190=
:34: error: packed attribute causes inefficient alignment for 'type' [-Werr=
or=3Dattributes]
>> >       190 |         __u16                    type;
>> >           |                                  ^~~~
>> >     cc1: all warnings being treated as errors
>> >     In file included from util/event=2Eh:12,
>> >                      from builtin-diff=2Ec:12:
>> >     /git/perf-6=2E0=2E0-rc1/tools/lib/perf/include/perf/event=2Eh:190=
:34: error: packed attribute causes inefficient alignment for 'type' [-Werr=
or=3Dattributes]
>> >       190 |         __u16                    type;
>> >           |                                  ^~~~
>> >     In file included from util/events_stats=2Eh:6,
>> >                      from util/evlist=2Eh:12,
>> >                      from builtin-evlist=2Ec:11:
>> >     /git/perf-6=2E0=2E0-rc1/tools/lib/perf/include/perf/event=2Eh:190=
:34: error: packed attribute causes inefficient alignment for 'type' [-Werr=
or=3Dattributes]
>> >       190 |         __u16                    type;
>> >           |                                  ^~~~
>> >
>> > So probably we need to disable this -Werror=3Dattributes in some
>> > architectures?
>>
>> Slapped this there:
>>
>> #pragma GCC diagnostic push
>> #pragma GCC diagnostic ignored "-Wpacked"
>> #pragma GCC diagnostic ignored "-Wattributes"
>>
>> struct __packed perf_record_cpu_map_data {
>>         __u16                    type;
>>         union {
>>                 /* Used when type =3D=3D PERF_CPU_MAP__CPUS=2E */
>>                 struct cpu_map_entries cpus_data;
>>                 /* Used when type =3D=3D PERF_CPU_MAP__MASK and long_si=
ze =3D=3D 4=2E */
>>                 struct perf_record_mask_cpu_map32 mask32_data;
>>                 /* Used when type =3D=3D PERF_CPU_MAP__MASK and long_si=
ze =3D=3D 8=2E */
>>                 struct perf_record_mask_cpu_map64 mask64_data;
>>         };
>> };
>>
>> #pragma GCC diagnostic pop
>
>Perhaps we should also carry a comment like:
>perf_record_cpu_map_data is packed as unfortunately an earlier version
>had unaligned data and we wish to retain file format compatibility=2E


Thanks, I'll add it=2E

- Arnaldo=20