[email protected], le mar. 03 mars 2026 04:08:15 +0000, a ecrit: > #### R-1: `ss->intr_port` and `ss->cancel` lack memory ordering (LOW on x86) > > **Files**: `hurd/signal.h:98,112`, `intr-msg.c:98`, `hurdsig.c:399` > > `intr_port` is `volatile` but without memory barriers. `cancel` isn't even > `volatile`. On x86 TSO, both are safe: volatile prevents compiler reordering, > and TSO provides hardware ordering. The `thread_suspend`/`thread_abort` > syscalls > act as implicit barriers. On weaker architectures (ARM, RISC-V), these would > need proper atomic operations. > > #### R-2: `ss->cancel = 0` written without lock (LOW on x86) > > **Files**: `intr-msg.c:292,304,380` > > The cancel flag is cleared without holding `ss->lock`, while > `hurd_thread_cancel()` sets it under the lock. On x86, aligned `int` writes > are atomic. The asm volatile in `INTR_MSG_TRAP` acts as a compiler barrier.
> #### H-7: `__pthread_total` uses relaxed ordering for last-thread check (LOW > on x86) > > **File**: `htl/pt-exit.c:60` > > ```c > if (atomic_fetch_add_relaxed (&__pthread_total, -1) == 1) > exit (0); > ``` > > Relaxed ordering is sufficient for the atomic decrement but not for the > "last thread" decision, which should synchronize with other threads' cleanup. > Safe on x86 TSO; incorrect on weakly-ordered architectures. > #### P-3: `pthread_once` uses plain load/store with fences (LOW on x86) > > **File**: `sysdeps/htl/pt-once.c:37-53` > > The double-checked locking pattern uses `atomic_full_barrier()` + plain > load/store rather than C11 atomics. Correct on x86; formally undefined > behavior in C11 due to data race on non-atomic accesses. These should probably be checked indeed. Samuel
