Guest ITIMER_REAL never fires in pause() or a spin loop
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- c
- Área
- operating-systems
Línea de trabajo
Start with sys_ppoll in src/syscall/poll.c and the timer checks in src/syscall/io.c, then trace how the vCPU watchdog and RLIMIT_CPU sampler kick a guest vCPU in src/syscall/proc.c and issue #475. Add coverage for the reported alarm(1) cases: pause() and a spin loop. Done means both guest processes terminate from SIGALRM near the timer expiry.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
A guest alarm() or setitimer(ITIMER_REAL) does not deliver SIGALRM while the guest sleeps in pause() or runs a loop with no syscalls. On Linux both end with SIGALRM when the timer expires.
elfuse keeps the guest ITIMER_REAL in guest_itimer (src/syscall/signal.c) instead of the host timer, since its own vCPU watchdog uses the host setitimer(ITIMER_REAL). The guest timer becomes a pending SIGALRM only when signal_check_timer or signal_check_timer_real runs: after a vCPU exit in src/syscall/proc.c, and inside the fd, futex and retry waits in src/syscall/io.c and src/runtime/futex.c. Two paths reach neither:
sys_ppollinsrc/syscall/poll.cwaits in hostpoll()slices and checkssignal_pending_interruption, but never callssignal_check_timer_real. glibc'spause()isppoll(NULL, 0, NULL, NULL), so it waits forever.- A guest spinning at EL0 takes no exit, so nothing checks the timer until the 10 s vCPU watchdog ends the process with a TIMEOUT crash report.
Reproduction, static aarch64 glibc:
#include <unistd.h>
int main(int argc, char **argv)
{
alarm(2);
if (argc > 1)
for (volatile unsigned long n = 0;; n++)
;
for (;;)
pause();
}
On Linux both ./a.out and ./a.out spin die of SIGALRM after 2 s. Under elfuse on main at e9fdbbb, both were still running when killed at 12 s, with the pause() case parked in sys_ppoll. The result is the same in a fork child and with a second thread that spins or sleeps.
Follow-ups
- Call
signal_check_timer_realin thesys_ppollwait loop and size the slice to the next guest timer expiry, as the fd wait insrc/syscall/io.cdoes. - Have the guest timer kick a spinning vCPU when it expires, the way the RLIMIT_CPU sampler in #475 raises attention, so a compute loop sees SIGALRM on time.
- Add a test:
alarm(1)thenpause(), andalarm(1)then a spin loop, each expected to die of SIGALRM.
- Lenguaje dominante
- C
- Estrellas
- 278
- Forks
- 31
- Merge medio
- 2 d 22 h
- PR fusionados (30 d)
- 17
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de sysprog21/elfuse
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 3 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 3 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 3 días
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
sysprog21/elfuse#476 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 3 días
Todos los issues de sysprog21/elfuse
Issues similares
-
vim.filetype.match() prefixes a URL buffer name with the cwd before passing it to filetype functionsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día
-
stream_curl: retry_count never resets after a successful reconnect, so long sequential streams die after 5 dropsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
mpv-player/mpv#18728 ·
Los mantenedores suelen responder en 1 día
-
followup Prio 📌
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
cyrusimap/cyrus-imapd#6640 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 60/100
Los mantenedores suelen responder en 1 día