From: Adrian Hunter <adrian.hunter@intel.com>
To: Ian Rogers <irogers@google.com>
Cc: "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@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Darren Hart" <dvhart@infradead.org>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"André Almeida" <andrealmeid@igalia.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Tom Rix" <trix@redhat.com>, "Weiguo Li" <liwg06@foxmail.com>,
"Athira Rajeev" <atrajeev@linux.vnet.ibm.com>,
"Thomas Richter" <tmricht@linux.ibm.com>,
"Ravi Bangoria" <ravi.bangoria@amd.com>,
"Dario Petrillo" <dario.pk1@gmail.com>,
Hewenliang <hewenliang4@huawei.com>,
yaowenbin <yaowenbin1@huawei.com>,
"Wenyu Liu" <liuwenyu7@huawei.com>,
"Song Liu" <songliubraving@fb.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Dave Marchevsky" <davemarchevsky@fb.com>,
"Leo Yan" <leo.yan@linaro.org>,
"Kim Phillips" <kim.phillips@amd.com>,
"Pavithra Gurushankar" <gpavithrasha@gmail.com>,
"Alexandre Truong" <alexandre.truong@arm.com>,
"Quentin Monnet" <quentin@isovalent.com>,
"William Cohen" <wcohen@redhat.com>,
"Andres Freund" <andres@anarazel.de>,
"Martin Liška" <mliska@suse.cz>,
"Colin Ian King" <colin.king@intel.com>,
"James Clark" <james.clark@arm.com>,
"Fangrui Song" <maskray@google.com>,
"Stephane Eranian" <eranian@google.com>,
"Kajol Jain" <kjain@linux.ibm.com>,
"Alexey Bayduraev" <alexey.v.bayduraev@linux.intel.com>,
"Riccardo Mancini" <rickyman7@gmail.com>,
"Andi Kleen" <ak@linux.intel.com>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Zechuan Chen" <chenzechuan1@huawei.com>,
"Jason Wang" <wangborong@cdjrlc.com>,
"Christophe JAILLET" <christophe.jaillet@wanadoo.fr>,
"Remi Bernon" <rbernon@codeweavers.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
bpf@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v3 09/18] perf ui: Update use of pthread mutex
Date: Fri, 26 Aug 2022 21:52:20 +0300 [thread overview]
Message-ID: <43540a3d-e64e-ec08-e12e-aebb236a2efe@intel.com> (raw)
In-Reply-To: <CAP-5=fW7t9tcJpyUbv8JAo-BFna-KS6FC+HkbuGx6S=h+nBMqw@mail.gmail.com>
On 26/08/22 20:45, Ian Rogers wrote:
> On Fri, Aug 26, 2022 at 10:22 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>
>> On 26/08/22 19:02, Ian Rogers wrote:
>>> On Fri, Aug 26, 2022 at 3:24 AM Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>>
>>>> On 24/08/22 18:38, Ian Rogers wrote:
>>>>> Switch to the use of mutex wrappers that provide better error checking.
>>>>>
>>>>> Signed-off-by: Ian Rogers <irogers@google.com>
>>>>> ---
>>>>> tools/perf/ui/browser.c | 20 ++++++++++----------
>>>>> tools/perf/ui/browsers/annotate.c | 2 +-
>>>>> tools/perf/ui/setup.c | 5 +++--
>>>>> tools/perf/ui/tui/helpline.c | 5 ++---
>>>>> tools/perf/ui/tui/progress.c | 8 ++++----
>>>>> tools/perf/ui/tui/setup.c | 8 ++++----
>>>>> tools/perf/ui/tui/util.c | 18 +++++++++---------
>>>>> tools/perf/ui/ui.h | 4 ++--
>>>>> 8 files changed, 35 insertions(+), 35 deletions(-)
>>>>>
>>>>> diff --git a/tools/perf/ui/browser.c b/tools/perf/ui/browser.c
>>>>> index fa5bd5c20e96..78fb01d6ad63 100644
>>>>> --- a/tools/perf/ui/browser.c
>>>>> +++ b/tools/perf/ui/browser.c
>>>>> @@ -268,9 +268,9 @@ void __ui_browser__show_title(struct ui_browser *browser, const char *title)
>>>>>
>>>>> void ui_browser__show_title(struct ui_browser *browser, const char *title)
>>>>> {
>>>>> - pthread_mutex_lock(&ui__lock);
>>>>> + mutex_lock(&ui__lock);
>>>>> __ui_browser__show_title(browser, title);
>>>>> - pthread_mutex_unlock(&ui__lock);
>>>>> + mutex_unlock(&ui__lock);
>>>>> }
>>>>>
>>>>> int ui_browser__show(struct ui_browser *browser, const char *title,
>>>>> @@ -284,7 +284,7 @@ int ui_browser__show(struct ui_browser *browser, const char *title,
>>>>>
>>>>> browser->refresh_dimensions(browser);
>>>>>
>>>>> - pthread_mutex_lock(&ui__lock);
>>>>> + mutex_lock(&ui__lock);
>>>>> __ui_browser__show_title(browser, title);
>>>>>
>>>>> browser->title = title;
>>>>> @@ -295,16 +295,16 @@ int ui_browser__show(struct ui_browser *browser, const char *title,
>>>>> va_end(ap);
>>>>> if (err > 0)
>>>>> ui_helpline__push(browser->helpline);
>>>>> - pthread_mutex_unlock(&ui__lock);
>>>>> + mutex_unlock(&ui__lock);
>>>>> return err ? 0 : -1;
>>>>> }
>>>>>
>>>>> void ui_browser__hide(struct ui_browser *browser)
>>>>> {
>>>>> - pthread_mutex_lock(&ui__lock);
>>>>> + mutex_lock(&ui__lock);
>>>>> ui_helpline__pop();
>>>>> zfree(&browser->helpline);
>>>>> - pthread_mutex_unlock(&ui__lock);
>>>>> + mutex_unlock(&ui__lock);
>>>>> }
>>>>>
>>>>> static void ui_browser__scrollbar_set(struct ui_browser *browser)
>>>>> @@ -352,9 +352,9 @@ static int __ui_browser__refresh(struct ui_browser *browser)
>>>>>
>>>>> int ui_browser__refresh(struct ui_browser *browser)
>>>>> {
>>>>> - pthread_mutex_lock(&ui__lock);
>>>>> + mutex_lock(&ui__lock);
>>>>> __ui_browser__refresh(browser);
>>>>> - pthread_mutex_unlock(&ui__lock);
>>>>> + mutex_unlock(&ui__lock);
>>>>>
>>>>> return 0;
>>>>> }
>>>>> @@ -390,10 +390,10 @@ int ui_browser__run(struct ui_browser *browser, int delay_secs)
>>>>> while (1) {
>>>>> off_t offset;
>>>>>
>>>>> - pthread_mutex_lock(&ui__lock);
>>>>> + mutex_lock(&ui__lock);
>>>>> err = __ui_browser__refresh(browser);
>>>>> SLsmg_refresh();
>>>>> - pthread_mutex_unlock(&ui__lock);
>>>>> + mutex_unlock(&ui__lock);
>>>>> if (err < 0)
>>>>> break;
>>>>>
>>>>> diff --git a/tools/perf/ui/browsers/annotate.c b/tools/perf/ui/browsers/annotate.c
>>>>> index 44ba900828f6..b8747e8dd9ea 100644
>>>>> --- a/tools/perf/ui/browsers/annotate.c
>>>>> +++ b/tools/perf/ui/browsers/annotate.c
>>>>> @@ -8,11 +8,11 @@
>>>>> #include "../../util/hist.h"
>>>>> #include "../../util/sort.h"
>>>>> #include "../../util/map.h"
>>>>> +#include "../../util/mutex.h"
>>>>> #include "../../util/symbol.h"
>>>>> #include "../../util/evsel.h"
>>>>> #include "../../util/evlist.h"
>>>>> #include <inttypes.h>
>>>>> -#include <pthread.h>
>>>>> #include <linux/kernel.h>
>>>>> #include <linux/string.h>
>>>>> #include <linux/zalloc.h>
>>>>> diff --git a/tools/perf/ui/setup.c b/tools/perf/ui/setup.c
>>>>> index 700335cde618..25ded88801a3 100644
>>>>> --- a/tools/perf/ui/setup.c
>>>>> +++ b/tools/perf/ui/setup.c
>>>>> @@ -1,5 +1,4 @@
>>>>> // SPDX-License-Identifier: GPL-2.0
>>>>> -#include <pthread.h>
>>>>> #include <dlfcn.h>
>>>>> #include <unistd.h>
>>>>>
>>>>> @@ -8,7 +7,7 @@
>>>>> #include "../util/hist.h"
>>>>> #include "ui.h"
>>>>>
>>>>> -pthread_mutex_t ui__lock = PTHREAD_MUTEX_INITIALIZER;
>>>>> +struct mutex ui__lock;
>>>>> void *perf_gtk_handle;
>>>>> int use_browser = -1;
>>>>>
>>>>> @@ -76,6 +75,7 @@ int stdio__config_color(const struct option *opt __maybe_unused,
>>>>>
>>>>> void setup_browser(bool fallback_to_pager)
>>>>> {
>>>>> + mutex_init(&ui__lock);
>>>>> if (use_browser < 2 && (!isatty(1) || dump_trace))
>>>>> use_browser = 0;
>>>>>
>>>>> @@ -118,4 +118,5 @@ void exit_browser(bool wait_for_ok)
>>>>> default:
>>>>> break;
>>>>> }
>>>>> + mutex_destroy(&ui__lock);
>>>>
>>>> Looks like exit_browser() can be called even when setup_browser()
>>>> was never called.
>>>>
>>>> Note, it also looks like PTHREAD_MUTEX_INITIALIZER is all zeros so
>>>> pthread won't notice.
>>>
>>> Memory sanitizer will notice some cases of this and so I didn't want
>>> to code defensively around exit being called ahead of setup.
>>
>> I am not sure you understood.
>>
>> As I wrote, exit_browser() can be called even when setup_browser()
>> was never called, so it is not defensive programming, it is necessary
>> programming that you only get away without doing because
>> PTHREAD_MUTEX_INITIALIZER is all zeros.
>
> Why are we here:
> 1) there is a memory leak
> 2) I fix the memory and trigger a use after free
> 3) I invent a reference count checker, use it to fix the memory leak,
> use after free and missing locks - the patch for this in 10s of lines
> long
> 4) when adding the lock fixes I defensively add error checking to the
> mutex involved - mainly because I was scared I could introduce a
> deadlock
> 5) I get asked to generalize this
> 6) GSoC contributor picks up and puts this down
> 7) I pull together the contributor's work
> 8) I get asked to turn a search and replace 4 patch fix into an unwieldy patch
> 9) I worry about the sanity of the change and add lock checking from clang
> 10) I end up trying to fix perf-sched who for some reason thought it
> was perfectly valid to have threads blocked on mutexes that were
> deallocated on the stack.
> 11) the UI code was written with a view that exiting something not
> setup somehow made sense
>
> I am drawing a line at fixing perf sched and the UI code. We can drop
> this patch and keep things as a pthread_mutex_t, similarly for
> perf-sched. I have gone about as far as I'm prepared to for the sake
> of a 10s of line memory leak fix. Some private thoughts are, it would
> be useful if review comments could be constructive, hey do this not
> that, and not simply commenting on change or trying to shoehorn vast
> amounts of tech debt clean up onto simple fixes.
If you want help, you only need ask.
Below seems adequate for now, at least logically, but maybe it
would confuse clang thread-safety analysis?
diff --git a/tools/perf/ui/setup.c b/tools/perf/ui/setup.c
index 25ded88801a3..6d81be6a349e 100644
--- a/tools/perf/ui/setup.c
+++ b/tools/perf/ui/setup.c
@@ -73,9 +73,17 @@ int stdio__config_color(const struct option *opt __maybe_unused,
return 0;
}
+/*
+ * exit_browser() can get called without setup_browser() having been called
+ * first, so it is necessary to keep track of whether ui__lock has been
+ * initialized.
+ */
+static bool ui__lock_initialized;
+
void setup_browser(bool fallback_to_pager)
{
mutex_init(&ui__lock);
+ ui__lock_initialized = true;
if (use_browser < 2 && (!isatty(1) || dump_trace))
use_browser = 0;
@@ -118,5 +126,6 @@ void exit_browser(bool wait_for_ok)
default:
break;
}
- mutex_destroy(&ui__lock);
+ if (ui__lock_initialized)
+ mutex_destroy(&ui__lock);
}
next prev parent reply other threads:[~2022-08-26 18:56 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 15:38 [PATCH v3 00/18] Mutex wrapper, locking and memory leak fixes Ian Rogers
2022-08-24 15:38 ` [PATCH v3 01/18] perf mutex: Wrapped usage of mutex and cond Ian Rogers
2022-08-26 8:49 ` Adrian Hunter
2022-08-24 15:38 ` [PATCH v3 02/18] perf bench: Update use of pthread mutex/cond Ian Rogers
2022-08-24 15:38 ` [PATCH v3 03/18] perf tests: Avoid pthread.h inclusion Ian Rogers
2022-08-24 15:38 ` [PATCH v3 04/18] perf hist: Update use of pthread mutex Ian Rogers
2022-08-24 15:38 ` [PATCH v3 05/18] perf bpf: Remove unused pthread.h include Ian Rogers
2022-08-24 15:38 ` [PATCH v3 06/18] perf lock: " Ian Rogers
2022-08-24 15:38 ` [PATCH v3 07/18] perf record: Update use of pthread mutex Ian Rogers
2022-08-24 15:38 ` [PATCH v3 08/18] perf sched: " Ian Rogers
2022-08-24 15:38 ` [PATCH v3 09/18] perf ui: " Ian Rogers
2022-08-26 10:11 ` Adrian Hunter
2022-08-26 16:01 ` Ian Rogers
2022-08-26 10:24 ` Adrian Hunter
2022-08-26 16:02 ` Ian Rogers
2022-08-26 17:22 ` Adrian Hunter
2022-08-26 17:45 ` Ian Rogers
2022-08-26 18:52 ` Adrian Hunter [this message]
2022-08-26 19:00 ` Namhyung Kim
2022-08-26 19:20 ` Adrian Hunter
2022-08-26 20:40 ` Namhyung Kim
2022-08-26 20:52 ` Ian Rogers
2022-08-27 7:11 ` Adrian Hunter
2022-08-24 15:38 ` [PATCH v3 10/18] perf mmap: Remove unnecessary pthread.h include Ian Rogers
2022-08-24 15:38 ` [PATCH v3 11/18] perf dso: Update use of pthread mutex Ian Rogers
2022-08-26 10:37 ` Adrian Hunter
2022-08-26 16:05 ` Ian Rogers
2022-08-26 17:34 ` Adrian Hunter
2022-08-26 17:46 ` Ian Rogers
2022-08-24 15:38 ` [PATCH v3 12/18] perf annotate: " Ian Rogers
2022-08-24 15:38 ` [PATCH v3 13/18] perf top: " Ian Rogers
2022-08-24 15:38 ` [PATCH v3 14/18] perf dso: Hold lock when accessing nsinfo Ian Rogers
2022-08-24 15:38 ` [PATCH v3 15/18] perf mutex: Add thread safety annotations Ian Rogers
2022-08-26 11:12 ` Adrian Hunter
2022-08-26 16:45 ` Arnaldo Carvalho de Melo
2022-08-26 17:00 ` Ian Rogers
2022-08-26 19:13 ` Arnaldo Carvalho de Melo
2022-08-24 15:38 ` [PATCH v3 16/18] perf sched: Fixes for thread safety analysis Ian Rogers
2022-08-26 12:12 ` Adrian Hunter
2022-08-26 16:06 ` Ian Rogers
2022-08-26 17:41 ` Adrian Hunter
2022-08-26 17:48 ` Ian Rogers
2022-08-26 18:26 ` Namhyung Kim
2022-08-26 19:35 ` Adrian Hunter
2022-08-26 20:48 ` Namhyung Kim
2022-08-24 15:39 ` [PATCH v3 17/18] perf top: " Ian Rogers
2022-08-24 15:39 ` [PATCH v3 18/18] perf build: Enable -Wthread-safety with clang Ian Rogers
[not found] ` <CA+JHD906M0truH7wPNZ=eJwdCA=qLhYDonUx_ZQBwJYpiX1hNg@mail.gmail.com>
2022-08-25 16:14 ` [PATCH v3 00/18] Mutex wrapper, locking and memory leak fixes Adrian Hunter
2022-08-26 12:36 ` Adrian Hunter
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=43540a3d-e64e-ec08-e12e-aebb236a2efe@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexandre.truong@arm.com \
--cc=alexey.v.bayduraev@linux.intel.com \
--cc=andrealmeid@igalia.com \
--cc=andres@anarazel.de \
--cc=andrii@kernel.org \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=chenzechuan1@huawei.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=colin.king@intel.com \
--cc=dario.pk1@gmail.com \
--cc=dave@stgolabs.net \
--cc=davemarchevsky@fb.com \
--cc=dvhart@infradead.org \
--cc=eranian@google.com \
--cc=gpavithrasha@gmail.com \
--cc=hewenliang4@huawei.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=kim.phillips@amd.com \
--cc=kjain@linux.ibm.com \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=liuwenyu7@huawei.com \
--cc=liwg06@foxmail.com \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=maskray@google.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=mliska@suse.cz \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=quentin@isovalent.com \
--cc=ravi.bangoria@amd.com \
--cc=rbernon@codeweavers.com \
--cc=rickyman7@gmail.com \
--cc=songliubraving@fb.com \
--cc=tglx@linutronix.de \
--cc=tmricht@linux.ibm.com \
--cc=trix@redhat.com \
--cc=wangborong@cdjrlc.com \
--cc=wcohen@redhat.com \
--cc=yaowenbin1@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 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).