All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: David Malcolm <dmalcolm@redhat.com>
Cc: Ian Rogers <irogers@google.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Jiri Olsa <jolsa@redhat.com>, Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Stephane Eranian <eranian@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 05/11] perf parse-event: Fix memory leak in evsel->unit
Date: Wed, 16 Sep 2020 16:12:24 +0900	[thread overview]
Message-ID: <CAM9d7cgtDq8yOFDEGEdTD9kN=Ko1gX=5o+tAB4+EDtN0WtGQPw@mail.gmail.com> (raw)
In-Reply-To: <0679eacce01f187037e726a45e6acdacde61f99d.camel@redhat.com>

Hello Ian and David,

Thank you for the good suggestions!

On Wed, Sep 16, 2020 at 4:56 AM David Malcolm <dmalcolm@redhat.com> wrote:
> Some ideas (with the caveat that I'm a GCC developer, and not a regular
> on LKML): can you capture the ownership status in the type system?
> I'm brainstorming here but how about:
>   typedef char *owned_string_t;
>   typedef const char *borrowed_string_t;
> This would at least capture the intent in human-readable form, and
> *might* make things more amenable to checking by a machine.  It's also
> less macro cruft.
> I take it that capturing the ownership status with a runtime flag next
> to the pointer in a struct is too expensive for your code?

Adding more random thoughts..

I think we can make it more generic like __attribute__((owned))
so that it can be applied to any pointers.  And we can use a
conventional macro like '__owned' in the declaration..

__owned char *name;
__owned char *strdup(const char *);
...

Thanks
Namhyung

  reply	other threads:[~2020-09-16  7:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15  3:18 [PATCHSET v2 00/11] perf tools: Fix various memory leaks Namhyung Kim
2020-09-15  3:18 ` [PATCH 01/11] perf metric: Fix some " Namhyung Kim
2020-09-15 11:58   ` Arnaldo Carvalho de Melo
2020-09-15  3:18 ` [PATCH 02/11] perf metric: Fix some memory leaks - part 2 Namhyung Kim
2020-09-15 11:59   ` Arnaldo Carvalho de Melo
2020-09-15  3:18 ` [PATCH 03/11] perf evlist: Fix cpu/thread map leak Namhyung Kim
2020-09-15  3:18 ` [PATCH 04/11] perf parse-event: Fix cpu map leaks Namhyung Kim
2020-09-15 12:18   ` Arnaldo Carvalho de Melo
2020-09-15 14:39     ` Namhyung Kim
2020-09-15 16:51       ` Arnaldo Carvalho de Melo
2020-09-15  3:18 ` [PATCH 05/11] perf parse-event: Fix memory leak in evsel->unit Namhyung Kim
2020-09-15 12:19   ` Arnaldo Carvalho de Melo
2020-09-15 18:59     ` Ian Rogers
2020-09-15 19:56       ` David Malcolm
2020-09-16  7:12         ` Namhyung Kim [this message]
2020-09-16 18:37           ` Ian Rogers
2020-09-15 20:03       ` Arnaldo Carvalho de Melo
2020-09-15  3:18 ` [PATCH 06/11] perf test: Fix memory leaks in parse-metric test Namhyung Kim
2020-09-15 12:23   ` Arnaldo Carvalho de Melo
2020-09-15  3:18 ` [PATCH 07/11] perf metric: Release expr_parse_ctx after testing Namhyung Kim
2020-09-15  3:18 ` [PATCH 08/11] perf metric: Free metric when it failed to resolve Namhyung Kim
2020-09-15 12:24   ` Arnaldo Carvalho de Melo
2020-09-15  3:18 ` [PATCH 09/11] perf metric: Do not free metric when " Namhyung Kim
2020-09-15  3:18 ` [PATCH 10/11] perf test: Free aliases for PMU event map aliases test Namhyung Kim
2020-09-15  7:37   ` John Garry
2020-09-15 11:57     ` Arnaldo Carvalho de Melo
2020-09-15  3:18 ` [PATCH 11/11] perf test: Free formats for perf pmu parse test Namhyung Kim
2020-09-15  5:15 ` [PATCHSET v2 00/11] perf tools: Fix various memory leaks Ian Rogers
2020-09-15 14:49   ` Namhyung Kim

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='CAM9d7cgtDq8yOFDEGEdTD9kN=Ko1gX=5o+tAB4+EDtN0WtGQPw@mail.gmail.com' \
    --to=namhyung@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dmalcolm@redhat.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@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 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.