Messages in this thread | | | From | Ian Rogers <> | Date | Tue, 24 Oct 2023 20:28:05 -0700 | Subject | Re: [PATCH v3 13/50] libperf: Lazily allocate mmap event copy |
| |
On Tue, Oct 24, 2023 at 7:39 PM Yang Jihong <yangjihong1@huawei.com> wrote: > > Hello, > > On 2023/10/25 6:23, Ian Rogers wrote: > > The event copy in the mmap is used to have storage to a read > > event. Not all users of mmaps read the events, such as perf record, so > > switch the allocation to being on first read rather than being > > embedded within the perf_mmap. > > > > Signed-off-by: Ian Rogers <irogers@google.com> > > --- > > tools/lib/perf/include/internal/mmap.h | 2 +- > > tools/lib/perf/mmap.c | 9 +++++++++ > > 2 files changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/tools/lib/perf/include/internal/mmap.h b/tools/lib/perf/include/internal/mmap.h > > index 5a062af8e9d8..b11aaf5ed645 100644 > > --- a/tools/lib/perf/include/internal/mmap.h > > +++ b/tools/lib/perf/include/internal/mmap.h > > @@ -33,7 +33,7 @@ struct perf_mmap { > > bool overwrite; > > u64 flush; > > libperf_unmap_cb_t unmap_cb; > > - char event_copy[PERF_SAMPLE_MAX_SIZE] __aligned(8); > > + void *event_copy; > > struct perf_mmap *next; > > }; > > > > diff --git a/tools/lib/perf/mmap.c b/tools/lib/perf/mmap.c > > index 2184814b37dd..91ae46aac378 100644 > > --- a/tools/lib/perf/mmap.c > > +++ b/tools/lib/perf/mmap.c > > @@ -51,6 +51,8 @@ int perf_mmap__mmap(struct perf_mmap *map, struct perf_mmap_param *mp, > > > > void perf_mmap__munmap(struct perf_mmap *map) > > { > > + free(map->event_copy); > > + map->event_copy = NULL; > > if (map && map->base != NULL) { > > munmap(map->base, perf_mmap__mmap_len(map)); > > map->base = NULL; > > @@ -226,6 +228,13 @@ static union perf_event *perf_mmap__read(struct perf_mmap *map, > > unsigned int len = min(sizeof(*event), size), cpy; > > void *dst = map->event_copy; > > > > + if (!dst) { > > + dst = malloc(PERF_SAMPLE_MAX_SIZE); > `event` is used as the return parameter of libperf API > perf_mmap__read_event(). > Is `zalloc` better to avoid dirty data?
We could but I'd prefer not to zero unnecessarily. We've had similar uninitialized memory being copied to perf.data file problems such as: http://lore.kernel.org/lkml/20210309234945.419254-1-irogers@google.com With the sanitizers help we can avoid the problem and do less work, which I think is best.
Thanks, Ian
> Thanks, > Yang
| |