linux-kernel - Re: [PATCH 05/11] perf parse-event: Fix memory leak in evsel->unit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAP-5=fWr0UVxp+JBcwzPV3=+EuUiBXuzHtaH5+1s1rCQb_dmdw@mail.gmail.com>
Date:   Wed, 16 Sep 2020 11:37:03 -0700
From:   Ian Rogers <irogers@...gle.com>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     David Malcolm <dmalcolm@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Stephane Eranian <eranian@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 05/11] perf parse-event: Fix memory leak in evsel->unit

On Wed, Sep 16, 2020 at 12:12 AM Namhyung Kim <namhyung@...nel.org> wrote:
>
> Hello Ian and David,
>
> Thank you for the good suggestions!
>
> On Wed, Sep 16, 2020 at 4:56 AM David Malcolm <dmalcolm@...hat.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

I have to say I like the idea of a __owned like "modifier" before
these names more than introducing types. David, do you think a patch
with something like the following is reasonable? I'm also throwing
this out there to see if somebody on the linux code side screams and
thinks this is the worst idea ever in existence :-)

compiler.h:
/* In the future __owned and __unowned will be an attribute to allow
static analysis to perform certain correctness checks. For now they
are placeholders to provide documentation. */
#define __owned
#define __unowned
..
evsel.h:
..
struct evsel {
  ..
  __owned char *name;
  ..
  __unowned const char *unit;
  ..

Thanks,
Ian