Re: Q.: Why does tty_ioctl.c: set_termios return EINTR instead of ERESTARTSYS?
From: Godmar Back
Date: Sat Oct 15 2011 - 09:13:16 EST
On Sat, Oct 15, 2011 at 4:55 AM, Jiri Slaby <jslaby@xxxxxxx> wrote:
>
> On 10/14/2011 06:52 PM, Godmar Back wrote:
> > A student in my OS class noticed during their shell assignment that
> > tcsetattr() is being interrupted with EINTR even though they had set
> > SA_RESTART.
> >
> > Upon taking a closer look, I noticed that
> > drivers/char/tty_ioctl.c:set_termios(), which lies on the code path
> > for the POSIX tcsetattr() function, returns -EINTR when a signal is
> > pending. Consequently, the SA_RESTART flag is not honored and user
> > code must check for and handle EINTR.
> >
> > I don't immediately see what would prevent this system call from being
> > restartable.
> >
> > Is there a particular reason why it cannot be made restartable?
>
> EINTR is used when there is no way to rollback already performed
> actions. In this case, a flush could be performed. (This holds only for
> TCSETSF, TCSETSF2 and similar.) So I think this is the reason we cannot
> return ERESTARTSYS.
TCSETSF flushes the terminal buffer (discarding input).
TCSETSW (which I believe is what the call I'm worried about uses:
tcsetattr(, TCSADRAIN,)) calls set_termios with TERMIOS_WAIT, which
results in a call to tty_wait_until_sent() that drains the terminal's
output buffer. See
http://lxr.linux.no/linux+v3.0.4/drivers/tty/tty_ioctl.c#L616
However, why would that necessitate EINTR? Both draining the output
buffer and flushing the input buffer are, presumably, idempotent
operations (?)
Furthermore, applications will most likely blindly retry on EINTR
anyway. For example, that's what user mode linux does/suggests (see
CATCH_EINTR in http://lxr.linux.no/linux+v3.0.4/arch/um/include/shared/os.h#L15
and http://lxr.linux.no/linux+v3.0.4/arch/um/drivers/chan_user.c#L108
) which is included with the Linux source tree.
- Godmar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/