pipe writes, ERESTARTSYS and SA_RESTART

[Viacheslav Biriukov]

Hi Yann,

Thank you for your time and quick response.

You are right. I found what misled me. It was a buffered writer to the
stdout, which did all my syscals restarts and it confused me.
The kernel does what it should, if a portion of data was written, then it's
a partial write, otherwise a restart if SA_RESTART is set.

Thank you for confirming that there are no changes in the kernel about the
syscalls restarts.

Have a good day!


On Thu, Aug 4, 2022 at 7:38 PM Yann Droneaud <ydroneaud at opteya.com> wrote:

> Hi,
>
> Le 04/08/2022 à 20:01, Viacheslav Biriukov a écrit :
> >
> > But what I can't understand is how and where the kernel modifies the
> > arguments of the write system call and where it collects the return
> > values of all these restarts, thus the userspace caller ultimately
> > sees the correct number of written bytes.
> >
> > With strace I can see all that retries, for example:
> >
> > write(1, ""..., 33554431)               = 65536
> > write(1, ""..., 33488895)               = ? ERESTARTSYS (To be
> > restarted if SA_RESTART is set)
> > write(1, ""..., 33488895)               = ? ERESTARTSYS (To be
> > restarted if SA_RESTART is set)
> > write(1, ""..., 33488895)               = ? ERESTARTSYS (To be
> > restarted if SA_RESTART is set)
> > write(1, ""..., 33488895)               = 33488895
> >
> > Here there were 4 restarts (I sent 4 signals), 3 of them returned
> > ERESTARTSYS and 2 were able to write to the pipe. Also for restarts
> > strace shows the correct 3rd argument, which is decrementing.
> >
> > The caller in the userspace in the end sees that it was able to write
> > 65536+33488895 bytes. Which is correct and what the man 7 pipe describes.
> >
> > My question is how and where it does that. I tried to dig in the
> > kernel source code but can't find the place where this tracking occurs.
> >
>
> It doesn't. SA_RESTART is only meant to retry syscall that would have
> returned EINTR.
>
> In such case, there's no tracking to do, because nothing was actually
> written, so the syscall can be restarted with the same parameters.
>
>
> Regards.
>
> --
>
> Yann Droneaud
>
> OPTEYA
>
>
>

-- 
Viacheslav Biriukov
BR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20220804/e5eb340b/attachment.html>