From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"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>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"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 15/18] perf mutex: Add thread safety annotations
Date: Fri, 26 Aug 2022 13:45:50 -0300 [thread overview]
Message-ID: <Ywj4vnYp6KGrrwl+@kernel.org> (raw)
In-Reply-To: <20220824153901.488576-16-irogers@google.com>
Em Wed, Aug 24, 2022 at 08:38:58AM -0700, Ian Rogers escreveu:
> Add thread safety annotations to struct mutex so that when compiled with
> clang's -Wthread-safety warnings are generated for erroneous lock
> patterns. NO_THREAD_SAFETY_ANALYSIS is needed for
> mutex_lock/mutex_unlock as the analysis doesn't under pthread calls.
So even having the guards checking if the attribute is available it
seems at least clang 11.0 is needed, as the "lockable" arg was
introduced there:
37 42.61 fedora:32 : FAIL clang version 10.0.1 (Fedora 10.0.1-3.fc32)
In file included from /git/perf-6.0.0-rc2/tools/perf/util/../ui/ui.h:5:
/git/perf-6.0.0-rc2/tools/perf/util/../ui/../util/mutex.h:74:8: error: invalid capability name 'lockable'; capability name must be 'mutex' or 'role' [-Werror,-Wthread-safety-attributes]
struct LOCKABLE mutex {
^
/git/perf-6.0.0-rc2/tools/perf/util/../ui/../util/mutex.h:35:44: note: expanded from macro 'LOCKABLE'
#define LOCKABLE __attribute__((capability("lockable")))
The next fedora releases are ok with it:
38 124.89 fedora:33 : Ok gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1) , clang version 11.0.0 (Fedora 11.0.0-3.fc33)
39 132.20 fedora:34 : Ok gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2) , clang version 12.0.1 (Fedora 12.0.1-1.fc34)
40 21.44 fedora:34-x-ARC-glibc : Ok arc-linux-gcc (ARC HS GNU/Linux glibc toolchain 2019.03-rc1) 8.3.1 20190225
41 19.43 fedora:34-x-ARC-uClibc : Ok arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225
42 136.33 fedora:35 : Ok gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-2) , clang version 13.0.0 (Fedora 13.0.0-3.fc35)
43 137.73 fedora:36 : Ok gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1) , clang version 14.0.0 (Fedora 14.0.0-1.fc36)
44 140.45 fedora:37 : Ok gcc (GCC) 12.1.1 20220628 (Red Hat 12.1.1-3) , clang version 14.0.5 (Fedora 14.0.5-6.fc37)
45 126.80 fedora:38 : Ok gcc (GCC) 12.1.1 20220810 (Red Hat 12.1.1-4) , clang version 14.0.5 (Fedora 14.0.5-6.fc38)
46 127.00 fedora:rawhide : Ok gcc (GCC) 12.1.1 20220810 (Red Hat 12.1.1-4) , clang version 14.0.5 (Fedora 14.0.5-6.fc38)
Is there a way to check if a "capability" is available for the
attribute? Otherwise we can additionally check the clang version?
For my tests I'll make clang 11.0 to be the oldest supported compiler
(i.e. just disable building with older versions), but wanted to let you
know since you try to check if the attribute is available and fallback
to doing nothing in that case.
- Arnaldo
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/util/mutex.c | 2 ++
> tools/perf/util/mutex.h | 72 ++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 69 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/util/mutex.c b/tools/perf/util/mutex.c
> index 892294ac1769..ec813093276d 100644
> --- a/tools/perf/util/mutex.c
> +++ b/tools/perf/util/mutex.c
> @@ -50,11 +50,13 @@ void mutex_destroy(struct mutex *mtx)
> }
>
> void mutex_lock(struct mutex *mtx)
> + NO_THREAD_SAFETY_ANALYSIS
> {
> CHECK_ERR(pthread_mutex_lock(&mtx->lock));
> }
>
> void mutex_unlock(struct mutex *mtx)
> + NO_THREAD_SAFETY_ANALYSIS
> {
> CHECK_ERR(pthread_mutex_unlock(&mtx->lock));
> }
> diff --git a/tools/perf/util/mutex.h b/tools/perf/util/mutex.h
> index c9e110a2b55e..48a2d87598f0 100644
> --- a/tools/perf/util/mutex.h
> +++ b/tools/perf/util/mutex.h
> @@ -5,11 +5,73 @@
> #include <pthread.h>
> #include <stdbool.h>
>
> +/*
> + * A function-like feature checking macro that is a wrapper around
> + * `__has_attribute`, which is defined by GCC 5+ and Clang and evaluates to a
> + * nonzero constant integer if the attribute is supported or 0 if not.
> + */
> +#ifdef __has_attribute
> +#define HAVE_ATTRIBUTE(x) __has_attribute(x)
> +#else
> +#define HAVE_ATTRIBUTE(x) 0
> +#endif
> +
> +
> +#if HAVE_ATTRIBUTE(guarded_by) && HAVE_ATTRIBUTE(pt_guarded_by) && \
> + HAVE_ATTRIBUTE(lockable) && HAVE_ATTRIBUTE(exclusive_lock_function) && \
> + HAVE_ATTRIBUTE(exclusive_trylock_function) && HAVE_ATTRIBUTE(exclusive_locks_required) && \
> + HAVE_ATTRIBUTE(no_thread_safety_analysis)
> +
> +/* Documents if a shared field or global variable needs to be protected by a mutex. */
> +#define GUARDED_BY(x) __attribute__((guarded_by(x)))
> +
> +/*
> + * Documents if the memory location pointed to by a pointer should be guarded by
> + * a mutex when dereferencing the pointer.
> + */
> +#define PT_GUARDED_BY(x) __attribute__((pt_guarded_by(x)))
> +
> +/* Documents if a type is a lockable type. */
> +#define LOCKABLE __attribute__((capability("lockable")))
> +
> +/* Documents functions that acquire a lock in the body of a function, and do not release it. */
> +#define EXCLUSIVE_LOCK_FUNCTION(...) __attribute__((exclusive_lock_function(__VA_ARGS__)))
> +
> +/*
> + * Documents functions that expect a lock to be held on entry to the function,
> + * and release it in the body of the function.
> + */
> +#define UNLOCK_FUNCTION(...) __attribute__((unlock_function(__VA_ARGS__)))
> +
> +/* Documents functions that try to acquire a lock, and return success or failure. */
> +#define EXCLUSIVE_TRYLOCK_FUNCTION(...) \
> + __attribute__((exclusive_trylock_function(__VA_ARGS__)))
> +
> +
> +/* Documents a function that expects a mutex to be held prior to entry. */
> +#define EXCLUSIVE_LOCKS_REQUIRED(...) __attribute__((exclusive_locks_required(__VA_ARGS__)))
> +
> +/* Turns off thread safety checking within the body of a particular function. */
> +#define NO_THREAD_SAFETY_ANALYSIS __attribute__((no_thread_safety_analysis))
> +
> +#else
> +
> +#define GUARDED_BY(x)
> +#define PT_GUARDED_BY(x)
> +#define LOCKABLE
> +#define EXCLUSIVE_LOCK_FUNCTION(...)
> +#define UNLOCK_FUNCTION(...)
> +#define EXCLUSIVE_TRYLOCK_FUNCTION(...)
> +#define EXCLUSIVE_LOCKS_REQUIRED(...)
> +#define NO_THREAD_SAFETY_ANALYSIS
> +
> +#endif
> +
> /*
> * A wrapper around the mutex implementation that allows perf to error check
> * usage, etc.
> */
> -struct mutex {
> +struct LOCKABLE mutex {
> pthread_mutex_t lock;
> };
>
> @@ -27,9 +89,9 @@ void mutex_init(struct mutex *mtx);
> void mutex_init_pshared(struct mutex *mtx);
> void mutex_destroy(struct mutex *mtx);
>
> -void mutex_lock(struct mutex *mtx);
> -void mutex_unlock(struct mutex *mtx);
> -bool mutex_trylock(struct mutex *mtx);
> +void mutex_lock(struct mutex *mtx) EXCLUSIVE_LOCK_FUNCTION(*mtx);
> +void mutex_unlock(struct mutex *mtx) UNLOCK_FUNCTION(*mtx);
> +bool mutex_trylock(struct mutex *mtx) EXCLUSIVE_TRYLOCK_FUNCTION(true, *mtx);
>
> /* Default initialize the cond struct. */
> void cond_init(struct cond *cnd);
> @@ -40,7 +102,7 @@ void cond_init(struct cond *cnd);
> void cond_init_pshared(struct cond *cnd);
> void cond_destroy(struct cond *cnd);
>
> -void cond_wait(struct cond *cnd, struct mutex *mtx);
> +void cond_wait(struct cond *cnd, struct mutex *mtx) EXCLUSIVE_LOCKS_REQUIRED(mtx);
> void cond_signal(struct cond *cnd);
> void cond_broadcast(struct cond *cnd);
>
> --
> 2.37.2.609.g9ff673ca1a-goog
--
- Arnaldo
next prev parent reply other threads:[~2022-08-26 16:45 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
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 [this message]
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=Ywj4vnYp6KGrrwl+@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--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