Hello, I'll separate out the discussion into the different issues.
Starting with the easiest. [email protected], le mar. 03 mars 2026 04:08:15 +0000, a ecrit: > The report also assesses recent fixes by Mike Kelly and Samuel > Thibault as correct, with one minor omission in the cancel_lock fix > (H-5: missing HURD_CRITICAL_BEGIN at pt-cond-timedwait.c:208). > ### Recent Fix: `cancel_lock` Critical Section (commit `c4a81e882e`) > > **Assessment: Mostly correct.** The fix wraps `cancel_lock` acquisition in > `HURD_CRITICAL_BEGIN`/`HURD_CRITICAL_END` to prevent signal delivery while > holding the lock (which would deadlock if the signal handler reached a > cancellation point). However, the second `cancel_lock` acquisition in > `pt-cond-timedwait.c:208` was **not** wrapped (see H-5 below). > #### H-5: Missing `HURD_CRITICAL_BEGIN` on second `cancel_lock` in condvar > (MEDIUM) > > **File**: `sysdeps/htl/pt-cond-timedwait.c:208-214` > > The Feb 2026 fix added critical sections around cancel_lock acquisitions in > most places, but missed the second acquisition at line 208 (post-blocking > cleanup). A signal arriving while this lock is held could deadlock if the > handler reaches a cancellation point. > > #### H-5 Proposed Fix: Wrap in `HURD_CRITICAL_BEGIN`/`HURD_CRITICAL_END` > > Same pattern as the first `cancel_lock` acquisition at line 121-151. > Replace lines 208-214: > > ```c > HURD_CRITICAL_BEGIN; > __pthread_mutex_lock (&self->cancel_lock); > self->cancel_hook = NULL; > self->cancel_hook_arg = NULL; > self->cancel_type = oldtype; > cancelled = (self->cancel_state == PTHREAD_CANCEL_ENABLE) > && self->cancel_pending; > __pthread_mutex_unlock (&self->cancel_lock); > HURD_CRITICAL_END; > ``` > 5. **Fix H-5**: Add `HURD_CRITICAL_BEGIN`/`HURD_CRITICAL_END` around the > cancel_lock acquisition at `pt-cond-timedwait.c:208`. Indeed! Missed that, now fixed. Samuel
