Hello, Michael Kelly, le sam. 21 juin 2025 21:40:27 +0100, a ecrit: > I found a deadlock situation involving 2 threads of a single process: > > Thread 0: calls alarm() to set the itimer timeout via __setitimer > (glibc/sysdeps/mach/hurd/setitimer.c). This locks _hurd_itimer_lock and then > attempts to lock _hurd_siglock (within setitimer_locked) to check whether > the global itimer signal preemptor has been registered. > > Thread 1: is involved in handling a SIGALRM within post_signal > (glibc/hurd/hurdsig.c). Just before it calls the global preemptors it locks > _hurd_siglock. The itimer preemptor is then called which attempts to lock > _hurd_itimer_lock. > > I made a small alteration to unlock and relock the _hurd_itimer_lock when > the _hurd_siglock is required within setitimer_locked. There is no state > within the function that is invalidated by the unlock/lock
Yes, there is. For instance, restart_itimer copies _hurd_itimerval.it_interval into `it', it expects that nothing modifies _hurd_itimerval in between so the timing computation is respected. I'd say rather make callers of setitimer_locked just always take _hurd_siglock first (or not for restart_itimer since it already has it) and drop the hurd_siglocked parameter. It seems much simpler to take the mutex spuriously in the setitimer(0) case than trying to fix this double-lock issue. Samuel
