From: Samuel Thibault Date: Wed, 4 Mar 2026 01:12:48 +0000 (+0100) Subject: hurd: Take cancel_lock in critical section X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7fdb0ab26444d0c5ad25b4e84cbd11cbaf3bb78c;p=thirdparty%2Fglibc.git hurd: Take cancel_lock in critical section read/write etc. shall be signal-safe, and take cancel_lock, so we have to defer signal delivery while holding cancel_lock. Reported-by: Brent Baccala 's Claude assistant --- diff --git a/sysdeps/htl/pt-cond-timedwait.c b/sysdeps/htl/pt-cond-timedwait.c index d350868c2b..7a5287ca9f 100644 --- a/sysdeps/htl/pt-cond-timedwait.c +++ b/sysdeps/htl/pt-cond-timedwait.c @@ -205,6 +205,7 @@ __pthread_cond_timedwait_internal (pthread_cond_t *cond, /* We're almost done. Remove the unblock hook, restore the previous cancellation type, and check for a pending cancellation request. */ + HURD_CRITICAL_BEGIN; __pthread_mutex_lock (&self->cancel_lock); self->cancel_hook = NULL; self->cancel_hook_arg = NULL; @@ -212,6 +213,7 @@ __pthread_cond_timedwait_internal (pthread_cond_t *cond, cancelled = (self->cancel_state == PTHREAD_CANCEL_ENABLE) && self->cancel_pending; __pthread_mutex_unlock (&self->cancel_lock); + HURD_CRITICAL_END; /* Reacquire MUTEX before returning/cancelling. */ __pthread_mutex_lock (mutex);