(stat(...) == -1 || faccessat(...) == -1) && errno == EINTR ?!??

[Tobias Bading]

Hello Konstantin,

thanks for trying to reproduce the problem. Could you please try

void handler (int signum)
{
}

and

timer.it_value.tv_usec = timer.it_interval.tv_usec = 1000000 / 10000;

to increase the rate of SIGALRMs to 10000 (or even higher) per second?
For me this reproduces the error also on shares that looked like they
weren't affected when only 50 signals per second were created. There
seems to be only a very short time window in which some piece of
(probably CIFS-related) kernel code can be thrown of the rails by a
signal, and the length of that time window probably depends on the
performance of client and server, the network connection and whatnot.
Since you're using a local share, your time window to produce the error
is probably much smaller than mine.

Tobias

---

On 14.02.21 18:56, Konstantin Kharlamov wrote:
> On Sun, 2021-02-14 at 13:18 +0100, Tobias Bading via Libc-help wrote:
>> Hello again.
>>
>> I've been able to reproduce the problem with the attached program. With
>> SIGALRMs firing 10 times per second, I get maybe a dozen "handler
>> called" lines before stat() or faccessat() fails with errno EINTR. When
>> I increase the rate to 50 SIGALRMs per second, the very first stat()
>> fails in every test run.
>>
>> Specifying SA_RESTART in sigaction() has no effect.
>>
>> Unfortunately, I don't have any other network shares available at the
>> moment to test whether only CIFS through VPN is affected, or the problem
>> would occur with e.g. NFS or CIFS without a VPN as well.
> Hello! So, I tried to reproduce this by creating a samba share, then mounting it with at `/tmp/mnt` by using a command:
>
>      sudo mount -t cifs -o username=guest,rw,exec,auto //127.0.0.1/export_bds mnt
>
> then I took your example, and modified the `path` variable to point to `/tmp/mnt`.
>
> Afterwards, it's been running for a minute I think, and I only ever seen `handler called` lines.
>
> So given other emails mentioned you may have stumbled upon a kernel bug, it apparently was fixed later. My kernel is 5.10.15, on Archlinux.
>
>