Hi Chris, On Sat, Jul 11 2026, Chris Hofstaedtler wrote:
> 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. it seems, this regression was fixed with: 87831fa19 (hardlink: fix performance regression (inefficient signal evaluation), 2025-04-29) The commit message says it improved performance by factor ten. Regards, Dirk > * 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. >>
