From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>
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: Re: [PATCH v2 4/6] perf cpumap: Fix alignment for masks in event encoding
Date: Fri, 19 Aug 2022 12:58:35 -0300 [thread overview]
Message-ID: <Yv+zK8UxUAP83zkp@kernel.org> (raw)
In-Reply-To: <Yv60COAP90TEiWkx@kernel.org>
Em Thu, Aug 18, 2022 at 06:50:00PM -0300, Arnaldo Carvalho de Melo escreveu:
> 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 pad
> > after long_size. This means 32-bit and 64-bit builds see the mask as
> > being at different offsets. On top of this the structure is in the 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. Consequently the long reads and writes are causing
> > undefined behavior as the alignment is broken.
> >
> > Fix the mask struct by creating explicit 32 and 64-bit variants, use a
> > union to avoid data[] and casts; the struct must be packed so the
> > layout matches the existing perf.data layout. 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.
> >
> > As the 64-bit version has 4 bytes of padding, optimizing writing to only
> > write the 32-bit version.
> >
> > Signed-off-by: Ian Rogers <irogers@google.com>
> > ---
> > tools/lib/perf/include/perf/event.h | 36 +++++++++++--
> > tools/perf/tests/cpumap.c | 19 ++++---
> > tools/perf/util/cpumap.c | 80 +++++++++++++++++++++++------
> > tools/perf/util/cpumap.h | 4 +-
> > tools/perf/util/session.c | 30 +++++------
> > tools/perf/util/synthetic-events.c | 34 +++++++-----
> > 6 files changed, 143 insertions(+), 60 deletions(-)
> >
> > diff --git a/tools/lib/perf/include/perf/event.h b/tools/lib/perf/include/perf/event.h
> > index e7758707cadd..d2d32589758a 100644
> > --- a/tools/lib/perf/include/perf/event.h
> > +++ b/tools/lib/perf/include/perf/event.h
> > @@ -6,6 +6,7 @@
> > #include <linux/types.h>
> > #include <linux/limits.h>
> > #include <linux/bpf.h>
> > +#include <linux/compiler.h>
> > #include <sys/types.h> /* pid_t */
> >
> > #define event_contains(obj, mem) ((obj).header.size > offsetof(typeof(obj), mem))
> > @@ -153,20 +154,47 @@ enum {
> > PERF_CPU_MAP__MASK = 1,
> > };
> >
> > +/*
> > + * Array encoding of a perf_cpu_map where nr is the number of entries in cpu[]
> > + * and each entry is a value for a CPU in the map.
> > + */
> > 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-bit. */
> > +struct perf_record_mask_cpu_map32 {
> > + /* Number of mask values. */
> > __u16 nr;
> > + /* Constant 4. */
> > __u16 long_size;
> > - unsigned long mask[];
> > + /* Bitmap data. */
> > + __u32 mask[];
> > };
> >
> > -struct perf_record_cpu_map_data {
> > +/* Bitmap encoding of a perf_cpu_map where bitmap entries are 64-bit. */
> > +struct perf_record_mask_cpu_map64 {
> > + /* Number of mask values. */
> > + __u16 nr;
> > + /* Constant 8. */
> > + __u16 long_size;
> > + /* Legacy padding. */
> > + char __pad[4];
> > + /* Bitmap data. */
> > + __u64 mask[];
> > +};
> > +
> > +struct __packed perf_record_cpu_map_data {
>
> In various places I'm getting this:
>
> [perfbuilder@five x-riscv]$ export BUILD_TARBALL=http://192.168.86.14/perf/perf-6.0.0-rc1.tar.xz
> [perfbuilder@five x-riscv]$ time dm .
> 1 5.47 ubuntu:22.04-x-riscv64 : FAIL gcc version 11.2.0 (Ubuntu 11.2.0-16ubuntu1)
> In file included from mmap.c:10:
> /git/perf-6.0.0-rc1/tools/lib/perf/include/perf/event.h:190:34: error: packed attribute causes inefficient alignment for 'type' [-Werror=attributes]
> 190 | __u16 type;
> | ^~~~
> cc1: all warnings being treated as errors
> In file included from util/event.h:12,
> from builtin-diff.c:12:
> /git/perf-6.0.0-rc1/tools/lib/perf/include/perf/event.h:190:34: error: packed attribute causes inefficient alignment for 'type' [-Werror=attributes]
> 190 | __u16 type;
> | ^~~~
> In file included from util/events_stats.h:6,
> from util/evlist.h:12,
> from builtin-evlist.c:11:
> /git/perf-6.0.0-rc1/tools/lib/perf/include/perf/event.h:190:34: error: packed attribute causes inefficient alignment for 'type' [-Werror=attributes]
> 190 | __u16 type;
> | ^~~~
>
> So probably we need to disable this -Werror=attributes 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 == PERF_CPU_MAP__CPUS. */
struct cpu_map_entries cpus_data;
/* Used when type == PERF_CPU_MAP__MASK and long_size == 4. */
struct perf_record_mask_cpu_map32 mask32_data;
/* Used when type == PERF_CPU_MAP__MASK and long_size == 8. */
struct perf_record_mask_cpu_map64 mask64_data;
};
};
#pragma GCC diagnostic pop
next prev parent reply other threads:[~2022-08-19 16:18 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 14:33 [PATCH v2 0/6] Corrections to cpu map event encoding Ian Rogers
2022-06-14 14:33 ` [PATCH v2 1/6] perf cpumap: Const map for max Ian Rogers
2022-06-14 14:33 ` [PATCH v2 2/6] perf cpumap: Synthetic events and const/static Ian Rogers
2022-06-14 14:33 ` [PATCH v2 3/6] perf cpumap: Compute mask size in constant time Ian Rogers
2022-06-14 14:33 ` [PATCH v2 4/6] perf cpumap: Fix alignment for masks in event encoding Ian Rogers
2022-06-14 22:44 ` Namhyung Kim
2022-06-14 23:51 ` Ian Rogers
2022-06-29 9:18 ` Jiri Olsa
2022-06-29 16:05 ` Ian Rogers
2022-08-18 21:50 ` Arnaldo Carvalho de Melo
2022-08-18 22:49 ` Ian Rogers
2022-08-19 15:58 ` Arnaldo Carvalho de Melo [this message]
2022-08-19 17:09 ` Ian Rogers
2022-08-19 17:28 ` Arnaldo Carvalho de Melo
2022-08-26 12:57 ` Alexander Gordeev
2022-08-26 16:20 ` Ian Rogers
2022-06-14 14:33 ` [PATCH v2 5/6] perf events: Prefer union over variable length array Ian Rogers
2022-06-14 14:33 ` [PATCH v2 6/6] perf cpumap: Add range data encoding Ian Rogers
2022-06-29 9:31 ` Jiri Olsa
2022-06-29 16:19 ` Ian Rogers
2022-07-31 12:39 ` Jiri Olsa
2022-08-04 19:30 ` Ian Rogers
2022-09-07 22:41 ` Ian Rogers
2022-09-07 23:47 ` Arnaldo Carvalho de Melo
2022-09-08 18:52 ` Arnaldo Carvalho de Melo
2022-07-15 17:01 ` [PATCH v2 0/6] Corrections to cpu map event encoding Ian Rogers
2022-07-29 2:01 ` Ian Rogers
2022-07-29 11:35 ` Jiri Olsa
2022-07-29 14:28 ` Ian Rogers
2022-07-31 12:37 ` Jiri Olsa
2022-08-04 20:23 ` Jiri Olsa
[not found] ` <CAP-5=fX-Ex1uv0hxCwDkkAyFV6VQNPRB5uSPpCDNgqu5ZV=bCA@mail.gmail.com>
2022-08-16 19:51 ` Arnaldo Carvalho de Melo
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=Yv+zK8UxUAP83zkp@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.v.bayduraev@linux.intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=colin.king@intel.com \
--cc=davemarchevsky@fb.com \
--cc=eranian@google.com \
--cc=german.gomez@arm.com \
--cc=gustavoars@kernel.org \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=keescook@chromium.org \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=rickyman7@gmail.com \
--cc=songliubraving@fb.com \
/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.