Re: Bug#1141670: util-linux: very slow code and undefined behaviour in handle_interrupt

Re: Bug#1141670: util-linux: very slow code and undefined behaviour in handle_interrupt

[Chris Hofstaedtler]

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 <debian-reportbug@plan9.de> [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.
>

Re: Bug#1141670: util-linux: very slow code and undefined behaviour in handle_interrupt

[Dirk Gouders]

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 <debian-reportbug@plan9.de> [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.
>>

Re: Bug#1141670: util-linux: very slow code and undefined behaviour in handle_interrupt

[Karel Zak]

On Sun, Jul 12, 2026 at 11:02:12AM +0200, Dirk Gouders wrote:
> 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.

Yes, it should be fixed in >=v2.41.1 and >=v2.42. Update :-)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com