From: Jiri Olsa <jolsa@redhat.com>
To: Stephane Eranian <eranian@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
mingo@elte.hu, Namhyung Kim <namhyung@kernel.org>
Subject: Re: [PATCHv3] perf tools: Add struct ordered_events_buffer layer
Date: Thu, 6 Sep 2018 15:28:59 +0200 [thread overview]
Message-ID: <20180906132859.GA9577@krava> (raw)
In-Reply-To: <CABPqkBTiDYm_pbFdbQCiNTpECVpWyOb16vBFC7AZ=vzqcR=2ig@mail.gmail.com>
On Mon, Sep 03, 2018 at 07:37:56PM -0700, Stephane Eranian wrote:
SNIP
>
> I think the code is correct now for the issue related to uninitialized pointer.
> But there is still one problem I found stressing the code with max_alloc_size.
> The way the following is written:
>
> if (!list_empty(cache)) {
> new = list_entry(cache->next, struct ordered_event, list);
> list_del(&new->list);
> } else if (oe->buffer) {
> new = oe->buffer + oe->buffer_idx;
> if (++oe->buffer_idx == MAX_SAMPLE_BUFFER)
> oe->buffer = NULL;
> } else if (oe->cur_alloc_size < oe->max_alloc_size) {
> size_t size = sizeof(*oe->buffer) MAX_SAMPLE_BUFFER *
> sizeof(*new);
>
> oe->buffer = malloc(size);
> if (!oe->buffer) {
> free_dup_event(oe, new_event);
> return NULL;
> }
>
> pr("alloc size %" PRIu64 "B (+%zu), max %" PRIu64 "B\n",
> oe->cur_alloc_size, size, oe->max_alloc_size);
>
> oe->cur_alloc_size += size;
>
> You can end up with oe->cur_alloc_size > oe->max_alloc_size in case
> the max limit is
> really low (< size_t size = sizeof (*oe->buffer) + MAX_SAMPLE_BUFFER *
> sizeof(*new);
> So I think to make sure you can never allocate more than the max, you
> have to do:
>
> size_t size = sizeof(*oe->buffer) MAX_SAMPLE_BUFFER * sizeof(*new);
> if (!list_empty(cache)) {
> new = list_entry(cache->next, struct ordered_event, list);
> list_del(&new->list);
> } else if (oe->buffer) {
> new = oe->buffer + oe->buffer_idx;
> if (++oe->buffer_idx == MAX_SAMPLE_BUFFER)
> oe->buffer = NULL;
> } else if ((oe->cur_alloc_size + size) < oe->max_alloc_size) {
>
> Then you will never allocate more than the max.
> I think with this change, we are okay.
> Tested-by: Stephane Eranian <eranian@google.com>
yep, makes sense.. something like below then
I'll post it on top of the previous patch
thanks,
jirka
---
diff --git a/tools/perf/util/ordered-events.c b/tools/perf/util/ordered-events.c
index 87171e8fd70d..2d1d0f3c8f77 100644
--- a/tools/perf/util/ordered-events.c
+++ b/tools/perf/util/ordered-events.c
@@ -101,6 +101,7 @@ static struct ordered_event *alloc_event(struct ordered_events *oe,
struct list_head *cache = &oe->cache;
struct ordered_event *new = NULL;
union perf_event *new_event;
+ size_t size;
new_event = dup_event(oe, event);
if (!new_event)
@@ -133,6 +134,8 @@ static struct ordered_event *alloc_event(struct ordered_events *oe,
* Removal of ordered event object moves it from events to
* the cache list.
*/
+ size = sizeof(*oe->buffer) + MAX_SAMPLE_BUFFER * sizeof(*new);
+
if (!list_empty(cache)) {
new = list_entry(cache->next, struct ordered_event, list);
list_del(&new->list);
@@ -140,10 +143,7 @@ static struct ordered_event *alloc_event(struct ordered_events *oe,
new = &oe->buffer->event[oe->buffer_idx];
if (++oe->buffer_idx == MAX_SAMPLE_BUFFER)
oe->buffer = NULL;
- } else if (oe->cur_alloc_size < oe->max_alloc_size) {
- size_t size = sizeof(*oe->buffer) +
- MAX_SAMPLE_BUFFER * sizeof(*new);
-
+ } else if ((oe->cur_alloc_size + size) < oe->max_alloc_size) {
oe->buffer = malloc(size);
if (!oe->buffer) {
free_dup_event(oe, new_event);
next prev parent reply other threads:[~2018-09-06 13:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-08 22:33 [PATCH v2] perf ordered_events: fix crash in free_dup_event() Stephane Eranian
2018-08-09 8:07 ` Jiri Olsa
2018-08-10 8:21 ` Stephane Eranian
2018-08-10 11:54 ` Jiri Olsa
2018-08-13 13:04 ` [PATCH] perf tools: Add struct ordered_events_buffer layer Jiri Olsa
2018-08-14 7:14 ` Stephane Eranian
2018-08-15 8:48 ` Jiri Olsa
2018-08-27 9:28 ` [PATCHv2] " Jiri Olsa
2018-08-27 11:07 ` Namhyung Kim
2018-08-27 15:24 ` Stephane Eranian
2018-08-27 17:05 ` [PATCHv3] " Jiri Olsa
2018-09-02 14:47 ` Jiri Olsa
2018-09-04 2:37 ` Stephane Eranian
2018-09-06 13:28 ` Jiri Olsa [this message]
2018-09-06 15:04 ` Stephane Eranian
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=20180906132859.GA9577@krava \
--to=jolsa@redhat.com \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/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.