linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Rogers <irogers@google.com>
To: "Peter Zijlstra" <peterz@infradead.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Jiri Olsa" <jolsa@redhat.com>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Darren Hart" <dvhart@infradead.org>,
	"Davidlohr Bueso" <dave@stgolabs.net>,
	"André Almeida" <andrealmeid@collabora.com>,
	"James Clark" <james.clark@arm.com>,
	"John Garry" <john.garry@huawei.com>,
	"Riccardo Mancini" <rickyman7@gmail.com>,
	"Yury Norov" <yury.norov@gmail.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jin Yao" <yao.jin@linux.intel.com>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Leo Yan" <leo.yan@linaro.org>, "Andi Kleen" <ak@linux.intel.com>,
	"Thomas Richter" <tmricht@linux.ibm.com>,
	"Kan Liang" <kan.liang@linux.intel.com>,
	"Madhavan Srinivasan" <maddy@linux.ibm.com>,
	"Shunsuke Nakamura" <nakamura.shun@fujitsu.com>,
	"Song Liu" <song@kernel.org>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Miaoqian Lin" <linmq006@gmail.com>,
	"Stephen Brennan" <stephen.s.brennan@oracle.com>,
	"Kajol Jain" <kjain@linux.ibm.com>,
	"Alexey Bayduraev" <alexey.v.bayduraev@linux.intel.com>,
	"German Gomez" <german.gomez@arm.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Eric Dumazet" <edumazet@google.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	masami.hiramatsu.pt@hitachi.com
Cc: eranian@google.com
Subject: Re: [PATCH v2 0/4] Reference count checker and related fixes
Date: Thu, 27 Jan 2022 13:33:23 -0800	[thread overview]
Message-ID: <CAP-5=fXyJeX3b3egcAOfPndmYhakrsdKu7HttnHEH2DKP-6Vxw@mail.gmail.com> (raw)
In-Reply-To: <20220125204602.4137477-1-irogers@google.com>

On Tue, Jan 25, 2022 at 12:46 PM Ian Rogers <irogers@google.com> wrote:
>
> This v2 patch set has the main reference count patch for cpu map from
> the first set and then adds reference count checking to nsinfo. The
> reference count checking on nsinfo helped diagnose a data race bug
> which is fixed in the independent patches 2 and 3.
>
> The perf tool has a class of memory problems where reference counts
> are used incorrectly. Memory/address sanitizers and valgrind don't
> provide useful ways to debug these problems, you see a memory leak
> where the only pertinent information is the original allocation
> site. What would be more useful is knowing where a get fails to have a
> corresponding put, where there are double puts, etc.
>
> This work was motivated by the roll-back of:
> https://lore.kernel.org/linux-perf-users/20211118193714.2293728-1-irogers@google.com/
> where fixing a missed put resulted in a use-after-free in a different
> context. There was a sense in fixing the issue that a game of
> wac-a-mole had been embarked upon in adding missed gets and puts.
>
> The basic approach of the change is to add a level of indirection at
> the get and put calls. Get allocates a level of indirection that, if
> no corresponding put is called, becomes a memory leak (and associated
> stack trace) that leak sanitizer can report. Similarly if two puts are
> called for the same get, then a double free can be detected by address
> sanitizer. This can also detect the use after put, which should also
> yield a segv without a sanitizer.
>
> Adding reference count checking to cpu map was done as a proof of
> concept, it yielded little other than a location where the use of get
> could be cleaner by using its result. Reference count checking on
> nsinfo identified a double free of the indirection layer and the
> related threads, thereby identifying a data race as discussed here:
> https://lore.kernel.org/linux-perf-users/CAP-5=fWZH20L4kv-BwVtGLwR=Em3AOOT+Q4QGivvQuYn5AsPRg@mail.gmail.com/
> Accordingly the dso->lock was extended and use to cover the race.
>
> An alternative that was considered was ref_tracker:
>  https://lwn.net/Articles/877603/
> ref_tracker requires use of a reference counted struct to also use a
> cookie/tracker. The cookie is combined with data in a ref_tracker_dir
> to spot double puts. When an object is finished with leaks can be
> detected, as with this approach when leak analysis happens. This
> approach was preferred as it doesn't introduce cookies, spots use
> after put and appears moderately more neutral to the API. Weaknesses
> of the implemented approcah are not being able to do adhoc leak
> detection and a preference for adding an accessor API to structs. I
> believe there are other issues and welcome suggestions.

And so we've been here before (Dec 2015 to be exact). Namhyung pointed me to:
https://lore.kernel.org/all/20151209021047.10245.8918.stgit@localhost.localdomain/
by Masami Hiramatsu. In this work he adds a leak sanitizer style
reference count checker that will describe locations of puts and gets
for diagnosis. Firstly that's an awesome achievement! This work is
different in that it isn't trying to invent a leak sanitizer, it is
just using the existing one. By adding a level of indirection this
work can catch use after put and pairs gets with puts to make lifetime
analysis more automatic. An advantage of Masami's work is that it
doesn't change data-structures and after the initial patch-set is
somewhat transparent. Overall I prefer the approach in these patches,
future patches can look to clean up the API as Masami has.

Thanks,
Ian

> Ian Rogers (4):
>   perf cpumap: Add reference count checking
>   perf dso: Make lock error check and add BUG_ONs
>   perf dso: Hold lock when accessing nsinfo
>   perf namespaces: Add reference count checking
>
>  tools/lib/perf/cpumap.c                  | 120 ++++++++++-----
>  tools/lib/perf/include/internal/cpumap.h |  14 +-
>  tools/perf/builtin-inject.c              |   6 +-
>  tools/perf/builtin-probe.c               |   2 +-
>  tools/perf/tests/cpumap.c                |  20 ++-
>  tools/perf/util/build-id.c               |   4 +-
>  tools/perf/util/cpumap.c                 |  42 ++---
>  tools/perf/util/dso.c                    |  17 ++-
>  tools/perf/util/jitdump.c                |  10 +-
>  tools/perf/util/map.c                    |   7 +-
>  tools/perf/util/namespaces.c             | 187 ++++++++++++++++-------
>  tools/perf/util/namespaces.h             |  23 ++-
>  tools/perf/util/pmu.c                    |  24 +--
>  tools/perf/util/probe-event.c            |   2 +
>  tools/perf/util/symbol.c                 |  10 +-
>  15 files changed, 337 insertions(+), 151 deletions(-)
>
> --
> 2.35.0.rc0.227.g00780c9af4-goog
>

  parent reply	other threads:[~2022-01-27 21:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 20:45 [PATCH v2 0/4] Reference count checker and related fixes Ian Rogers
2022-01-25 20:45 ` [PATCH v2 1/4] perf cpumap: Add reference count checking Ian Rogers
2022-01-31 14:44   ` Arnaldo Carvalho de Melo
2022-01-25 20:46 ` [PATCH v2 2/4] perf dso: Make lock error check and add BUG_ONs Ian Rogers
2022-01-25 20:46 ` [PATCH v2 3/4] perf dso: Hold lock when accessing nsinfo Ian Rogers
2022-01-25 20:46 ` [PATCH v2 4/4] perf namespaces: Add reference count checking Ian Rogers
2022-01-27 21:33 ` Ian Rogers [this message]
2022-01-28  5:23   ` [PATCH v2 0/4] Reference count checker and related fixes Masami Hiramatsu
2022-01-28  6:24     ` Ian Rogers
2022-01-28 15:34       ` Masami Hiramatsu
2022-01-28 18:26         ` Ian Rogers
2022-01-28 19:59           ` Arnaldo Carvalho de Melo
2022-01-30  8:04             ` Masami Hiramatsu
2022-01-31 14:28               ` Arnaldo Carvalho de Melo
2022-01-30  7:54           ` Masami Hiramatsu
2022-01-30 17:40             ` Ian Rogers
2022-02-04 14:57               ` Masami Hiramatsu
2022-02-04 19:11                 ` Ian Rogers
2022-02-05  4:41                   ` Masami Hiramatsu
2022-01-31 13:56           ` Arnaldo Carvalho de Melo

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='CAP-5=fXyJeX3b3egcAOfPndmYhakrsdKu7HttnHEH2DKP-6Vxw@mail.gmail.com' \
    --to=irogers@google.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=alexey.v.bayduraev@linux.intel.com \
    --cc=andrealmeid@collabora.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dave@stgolabs.net \
    --cc=dvhart@infradead.org \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=eranian@google.com \
    --cc=german.gomez@arm.com \
    --cc=james.clark@arm.com \
    --cc=john.garry@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=kan.liang@linux.intel.com \
    --cc=kjain@linux.ibm.com \
    --cc=leo.yan@linaro.org \
    --cc=linmq006@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=mark.rutland@arm.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nakamura.shun@fujitsu.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rickyman7@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=song@kernel.org \
    --cc=stephen.s.brennan@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=tmricht@linux.ibm.com \
    --cc=yao.jin@linux.intel.com \
    --cc=yury.norov@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).