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>,
Adrian Hunter <adrian.hunter@intel.com>,
Rob Herring <robh@kernel.org>,
Kan Liang <kan.liang@linux.intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] perf parse-events: Avoid string for PE_BP_COLON, PE_BP_SLASH
Date: Tue, 13 Jun 2023 16:41:43 -0300 [thread overview]
Message-ID: <ZIjGd79uWxgRF0og@kernel.org> (raw)
In-Reply-To: <20230613182629.1500317-1-irogers@google.com>
Em Tue, Jun 13, 2023 at 11:26:29AM -0700, Ian Rogers escreveu:
> There's no need to read the string ':' or '/' for PE_BP_COLON or
> PE_BP_SLASH and doing so causes parse-events.y to leak memory.
>
> The original patch has a committer note about not using these tokens
> presumably as yacc spotted they were a memory leak because no
> %destructor could be run. Remove the unused token workaround as there
> is now no value associated with these tokens.
It looked like the compiler was the one warning (-Wother) about args not
being used, didn't made it clear those were possible memory leaks :-\
util/parse-events.y:508.24-34: warning: unused value: $3 [-Wother]
508 | PE_PREFIX_MEM PE_VALUE PE_BP_SLASH PE_VALUE PE_BP_COLON PE_MODIFIER_BP opt_event_config
Anyway, I'll apply and test your patch.
- Arnaldo
> Fixes: f0617f526cb0 ("perf parse: Allow config terms with breakpoints")
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/util/parse-events.h | 4 ----
> tools/perf/util/parse-events.l | 4 ++--
> tools/perf/util/parse-events.y | 9 ---------
> 3 files changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
> index 5fdc1f33f57e..b0eb95f93e9c 100644
> --- a/tools/perf/util/parse-events.h
> +++ b/tools/perf/util/parse-events.h
> @@ -228,10 +228,6 @@ void parse_events_error__handle(struct parse_events_error *err, int idx,
> void parse_events_error__print(struct parse_events_error *err,
> const char *event);
>
> -static inline void parse_events_unused_value(const void *x __maybe_unused)
> -{
> -}
> -
> #ifdef HAVE_LIBELF_SUPPORT
> /*
> * If the probe point starts with '%',
> diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
> index 7629af3d5c7c..99335ec586ae 100644
> --- a/tools/perf/util/parse-events.l
> +++ b/tools/perf/util/parse-events.l
> @@ -315,13 +315,13 @@ r0x{num_raw_hex} { return str(yyscanner, PE_RAW); }
> * are the same, so trailing context can be used disambiguate the two
> * cases.
> */
> -":"/{modifier_bp} { return str(yyscanner, PE_BP_COLON); }
> +":"/{modifier_bp} { return PE_BP_COLON; }
> /*
> * The slash before memory length can get mixed up with the slash before
> * config terms. Fortunately config terms do not start with a numeric
> * digit, so trailing context can be used disambiguate the two cases.
> */
> -"/"/{digit} { return str(yyscanner, PE_BP_SLASH); }
> +"/"/{digit} { return PE_BP_SLASH; }
> "/"/{non_digit} { BEGIN(config); return '/'; }
> {num_dec} { return value(yyscanner, 10); }
> {num_hex} { return value(yyscanner, 16); }
> diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
> index 0c3d086cc22a..9f28d4b5502f 100644
> --- a/tools/perf/util/parse-events.y
> +++ b/tools/perf/util/parse-events.y
> @@ -80,8 +80,6 @@ static void free_list_evsel(struct list_head* list_evsel)
> %type <str> PE_LEGACY_CACHE
> %type <str> PE_MODIFIER_EVENT
> %type <str> PE_MODIFIER_BP
> -%type <str> PE_BP_COLON
> -%type <str> PE_BP_SLASH
> %type <str> PE_EVENT_NAME
> %type <str> PE_KERNEL_PMU_EVENT PE_PMU_EVENT_FAKE
> %type <str> PE_DRV_CFG_TERM
> @@ -510,9 +508,6 @@ PE_PREFIX_MEM PE_VALUE PE_BP_SLASH PE_VALUE PE_BP_COLON PE_MODIFIER_BP opt_event
> struct list_head *list;
> int err;
>
> - parse_events_unused_value(&$3);
> - parse_events_unused_value(&$5);
> -
> list = alloc_list();
> ABORT_ON(!list);
> err = parse_events_add_breakpoint(_parse_state, list,
> @@ -531,8 +526,6 @@ PE_PREFIX_MEM PE_VALUE PE_BP_SLASH PE_VALUE opt_event_config
> struct list_head *list;
> int err;
>
> - parse_events_unused_value(&$3);
> -
> list = alloc_list();
> ABORT_ON(!list);
> err = parse_events_add_breakpoint(_parse_state, list,
> @@ -550,8 +543,6 @@ PE_PREFIX_MEM PE_VALUE PE_BP_COLON PE_MODIFIER_BP opt_event_config
> struct list_head *list;
> int err;
>
> - parse_events_unused_value(&$3);
> -
> list = alloc_list();
> ABORT_ON(!list);
> err = parse_events_add_breakpoint(_parse_state, list,
> --
> 2.41.0.162.gfafddb0af9-goog
>
--
- Arnaldo
next prev parent reply other threads:[~2023-06-13 19:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 18:26 [PATCH v1] perf parse-events: Avoid string for PE_BP_COLON, PE_BP_SLASH Ian Rogers
2023-06-13 19:41 ` Arnaldo Carvalho de Melo [this message]
2023-06-13 20:26 ` Ian Rogers
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=ZIjGd79uWxgRF0og@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--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=robh@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox