From a987943be74e59e0383b7a5b4b5fa2c47c3ab578 Mon Sep 17 00:00:00 2001 From: Mathieu Desnoyers Date: Wed, 6 Apr 2022 11:16:06 -0400 Subject: [PATCH] Document ust lock async-signal-safety Signed-off-by: Mathieu Desnoyers Change-Id: Ie150d5757cc050b0262dcea20f20c1da4963a27e --- src/lib/lttng-ust/lttng-ust-comm.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/src/lib/lttng-ust/lttng-ust-comm.c b/src/lib/lttng-ust/lttng-ust-comm.c index 384a6a58..10883e96 100644 --- a/src/lib/lttng-ust/lttng-ust-comm.c +++ b/src/lib/lttng-ust/lttng-ust-comm.c @@ -118,6 +118,28 @@ static int lttng_ust_comm_should_quit; */ int lttng_ust_loaded __attribute__((weak)); +/* + * Notes on async-signal-safety of ust lock: a few libc functions are used + * which are not strictly async-signal-safe: + * + * - pthread_setcancelstate + * - pthread_mutex_lock + * - pthread_mutex_unlock + * + * As of glibc 2.35, the implementation of pthread_setcancelstate only + * touches TLS data, and it appears to be safe to use from signal + * handlers. If the libc implementation changes, this will need to be + * revisited, and we may ask glibc to provide an async-signal-safe + * pthread_setcancelstate. + * + * As of glibc 2.35, the implementation of pthread_mutex_lock/unlock + * for fast mutexes only relies on the pthread_mutex_t structure. + * Disabling signals around all uses of this mutex ensures + * signal-safety. If the libc implementation changes and eventually uses + * other global resources, this will need to be revisited and we may + * need to implement our own mutex. + */ + /* * Return 0 on success, -1 if should quit. * The lock is taken in both cases. -- 2.34.1