[email protected], le mar. 03 mars 2026 04:08:15 +0000, a ecrit: > #### POSIX-1: `pthread_kill` is not async-signal-safe (HIGH) > > **POSIX** (XSH §2.4.3 *Signal Actions*): > Table of async-signal-safe functions lists `pthread_kill()`. > > **Implementation** (`sysdeps/hurd/htl/pt-kill.c:44`): Calls > `_hurd_thread_sigstate(pthread->kernel_thread)` which takes > `__mutex_lock(&_hurd_siglock)` (`hurdsig.c:82`). If the calling thread > already holds `_hurd_siglock` when a signal is delivered (the signal thread > defers delivery only for `critical_section_lock`, not for `_hurd_siglock`), > a signal handler calling `pthread_kill` will self-deadlock. > > The lookup is redundant: by the time `pthread_kill` can be called, the > target's sigstate was already created during `__pthread_sigstate_init` > (`pt-sigstate-init.c:38`). The `malloc` path in `_hurd_thread_sigstate` > (`hurdsig.c:88`) is never reached. > > #### POSIX-1 Proposed Fix: Wrap `_hurd_siglock` in a critical section > > The H-1 fix replaces `_hurd_thread_sigstate` with a lookup-only scan but > still takes `_hurd_siglock`. Wrap that section in a Hurd critical section: > > ```c > HURD_CRITICAL_BEGIN; > __mutex_lock (&_hurd_siglock); > for (ss = _hurd_sigstates; ss != NULL; ss = ss->next) > if (ss->thread == pthread->kernel_thread) > break; > if (ss != NULL) > __spin_lock (&ss->lock); > __mutex_unlock (&_hurd_siglock); > HURD_CRITICAL_END; > ``` > > `_hurd_critical_section_lock` uses TLS (`THREAD_GETMEM(THREAD_SELF, > _hurd_sigstate)`) — no locks, no `_hurd_siglock`. While the critical section > is held, the signal thread defers delivery to this thread. So a signal > handler in this thread cannot run while `_hurd_siglock` is held, eliminating > the self-deadlock.
This is indeed an issue. We need to take a complete look at the functions which are supposed to be async-signal-safe, to check which locks they take and put taking them in critical sections. Samuel
