From: Jiri Olsa <jolsa@redhat.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>, David Ahern <dsahern@gmail.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Kan Liang <kan.liang@intel.com>, Andi Kleen <ak@linux.intel.com>,
Lukasz Odzioba <lukasz.odzioba@intel.com>,
Wang Nan <wangnan0@huawei.com>,
kernel-team@lge.com
Subject: Re: [PATCH 1/4] perf tools: Fix struct comm_str removal crash
Date: Tue, 17 Jul 2018 11:02:45 +0200 [thread overview]
Message-ID: <20180717090245.GB8631@krava> (raw)
In-Reply-To: <20180717014940.GA9295@sejong>
On Tue, Jul 17, 2018 at 10:49:40AM +0900, Namhyung Kim wrote:
> Hi Jiri,
>
> On Mon, Jul 16, 2018 at 12:29:34PM +0200, Jiri Olsa wrote:
> > On Sun, Jul 15, 2018 at 10:08:27PM +0900, Namhyung Kim wrote:
> >
> > SNIP
> >
> > > > Because thread 2 first decrements the refcnt and only after then it
> > > > removes the struct comm_str from the list, the thread 1 can find this
> > > > object on the list with refcnt equls to 0 and hit the assert.
> > > >
> > > > This patch fixes the thread 2 path, by removing the struct comm_str
> > > > FIRST from the list and only AFTER calling comm_str__put on it. This
> > > > way the thread 1 finds only valid objects on the list.
> > >
> > > I'm not sure we can unconditionally remove the comm_str from the tree.
> > > It should be removed only if refcount is going to zero IMHO.
> > > Otherwise it could end up having multiple comm_str entry for a same
> > > name.
> >
> > right, but it wouldn't crash ;-)
> >
> > how about attached change, that actualy deals with the refcnt
> > race I'm running the tests now, seems ok so far
>
> I think we can keep if the refcount is back to non-zero. What about this?
> (not tested..)
>
>
> static struct comm_str *comm_str__get(cs)
> {
> if (cs)
> refcount_inc_no_warn(&cs->refcnt); // should be added
> return cs;
> }
>
> static void comm_str__put(cs)
> {
> if (cs && refcount_dec_and_test(&cs->refcnt)) {
> down_write(&comm_str_lock);
> /* might race with comm_str__findnew() */
> if (!refcount_read(&cs->refcnt)) {
> rb_erase(&cs->rb_node, &comm_str_root);
> zfree(&cs->str);
> free(cs);
> }
> up_write(&comm_str_lock);
> }
> }
yea, it's more possitive than my patch
I'm testing attached patch, looks good so far
thanks,
jirka
---
diff --git a/tools/include/linux/refcount.h b/tools/include/linux/refcount.h
index 36cb29bc57c2..11e2be6f68a0 100644
--- a/tools/include/linux/refcount.h
+++ b/tools/include/linux/refcount.h
@@ -109,6 +109,14 @@ static inline void refcount_inc(refcount_t *r)
REFCOUNT_WARN(!refcount_inc_not_zero(r), "refcount_t: increment on 0; use-after-free.\n");
}
+/*
+ * Pure refs increase without any chec/warn.
+ */
+static inline void refcount_inc_no_warn(refcount_t *r)
+{
+ atomic_inc(&r->refs);
+}
+
/*
* Similar to atomic_dec_and_test(), it will WARN on underflow and fail to
* decrement when saturated at UINT_MAX.
diff --git a/tools/perf/util/comm.c b/tools/perf/util/comm.c
index 7798a2cc8a86..a2e338cf29d7 100644
--- a/tools/perf/util/comm.c
+++ b/tools/perf/util/comm.c
@@ -21,7 +21,7 @@ static struct rw_semaphore comm_str_lock = {.lock = PTHREAD_RWLOCK_INITIALIZER,}
static struct comm_str *comm_str__get(struct comm_str *cs)
{
if (cs)
- refcount_inc(&cs->refcnt);
+ refcount_inc_no_warn(&cs->refcnt);
return cs;
}
@@ -29,10 +29,12 @@ static void comm_str__put(struct comm_str *cs)
{
if (cs && refcount_dec_and_test(&cs->refcnt)) {
down_write(&comm_str_lock);
- rb_erase(&cs->rb_node, &comm_str_root);
+ if (refcount_read(&cs->refcnt) == 0) {
+ rb_erase(&cs->rb_node, &comm_str_root);
+ zfree(&cs->str);
+ free(cs);
+ }
up_write(&comm_str_lock);
- zfree(&cs->str);
- free(cs);
}
}
next prev parent reply other threads:[~2018-07-17 9:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-12 14:20 [PATCH 0/4] perf tools: Fix top crashes Jiri Olsa
2018-07-12 14:20 ` [PATCH 1/4] perf tools: Fix struct comm_str removal crash Jiri Olsa
2018-07-15 13:08 ` Namhyung Kim
2018-07-16 10:29 ` Jiri Olsa
2018-07-17 1:49 ` Namhyung Kim
2018-07-17 9:02 ` Jiri Olsa [this message]
2018-07-18 10:44 ` Jiri Olsa
2018-07-12 14:20 ` [PATCH 2/4] perf tools: Add threads__get_last_match function Jiri Olsa
2018-07-22 7:53 ` [lkp-robot] [perf tools] 600b7378cf: perf-sanity-tests.Share_thread_mg.fail kernel test robot
2018-07-22 7:53 ` kernel test robot
2018-07-23 6:59 ` Jiri Olsa
2018-07-23 6:59 ` Jiri Olsa
2018-07-12 14:20 ` [PATCH 3/4] perf tools: Add threads__set_last_match function Jiri Olsa
2018-07-12 14:20 ` [PATCH 4/4] perf tools: Use last_match threads cache only in single thread mode Jiri Olsa
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=20180717090245.GB8631@krava \
--to=jolsa@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dsahern@gmail.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.odzioba@intel.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=wangnan0@huawei.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 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.