Re: Deadlock with SIGALRM handling

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