Re: Bug#1141670: util-linux: very slow code and undefined behaviour in handle_interrupt
Chris Hofstaedtler <[email protected]> Sat, 11 Jul 2026 19:34:41 -0300
| Newsgroups | org.kernel.vger.util-linux |
|---|---|
| Message-ID | <[email protected]> |
Hi util-linux maintainers, the following was reported to Debian, regarding the hardlink utility. It appears to be an upstream issue. Maybe someone can look at it. CC:ing наб who seems to have touched the relevant function last. Thanks, Chris * Marc Lehmann <[email protected]> [260708 07:23]: >Version: 2.41-5 > >Dear Maintainer, > >while strace'ing to find out why hardlink is so slow, IO found it does this sequence between every fstatat call: > > gettid() = 36482 > getpid() = 36482 > tgkill(36482, 36482, 0) = 0 > >this seems to be a pretty weird thing to do in a tighht scanning >loop. Looking at the code, handle_interrupt is responsible: > > /** > * handle_interrupt - Handle a signal > */ > static void handle_interrupt(void) > { > switch (last_signal) { > case SIGUSR1: > print_stats(); > putchar('\n'); > break; > default: > signal(last_signal, SIG_DFL); > raise(last_signal); > break; > } > last_signal = 0; > } > >this is already a weird function to begin with, but crucially, it calls signal(0,... and raise(0). > >it seems to me the former is likely undefined behaviour and the latter is >just unnecessartily slow. > >most likely, handle_interrupt simply should not be called after every fstatat, or at all, without last_signal bering set beforehand. >