[PATCH] prevent retries on fclose/fflush after write errors

Rich Felker dalias at aerifal.cx
Thu Mar 15 00:09:06 UTC 2012

On Wed, Mar 14, 2012 at 02:26:06PM +0100, Johannes Stezenbach wrote:
> On Tue, Mar 13, 2012 at 10:58:33AM -0400, Rich Felker wrote:
> > On Tue, Mar 13, 2012 at 10:30:10AM +0100, Laurent Bercot wrote:
> > 
> > >  Why not simply let the user set SA_RESTART in the sigaction() call?
> > > see http://www.skarnet.org/software/skalibs/libstddjb/safewrappers.html
> > 
> > I know of no modern system where this kind of bogus EINTR happens
> > (SIGSTOP, etc.). Even the proprietary unices fixed it before Linux
> > did, but they've all been fixed for a long time now. I agree the
> > standard should be more explicit on this; failure to be explicit, if
> > you interpret it literally, makes interrupting signals unusable since
> > you have to wrap all your syscalls with loops and make them behave as
> > if the signal was a restarting one..
> FWIW, Michael Kerrisk's book "The Linux Programming Interface"
> lists a number of syscalls which can return EINTR after resume
> from SIGSTOP.

It's outdated. See man 7 signal for details on what has/hasn't been
fixed. The only ones still broken are all in the "timed wait" family,
for which isn't not that big a deal to return early anyway since the
caller expects that a timed wait operation might fail with a timeout
and already has to deal with this error case.

>  Normal read() is not one of them, but e.g. read() from
> inotify fd is.

While this is broken in principle, inotify is enough of an oddball
(and only really usable paired with select/poll anyway) that it
probably doesn't matter.

> I would also expect that some character devices
> do not implement restarting for read() and write(), if just
> because ERESTARTSYS etc. are not sufficiently documented.

I'm not aware of any such issues, at least not with the devices normal
user apps would interface with. The main type, terminals, are not
buggy in this regard (but are buggy in regard to readv/writev in a
different manner).

It's actually really frustrating that Linux exposes the potential
brokenness of each underlying driver to the application. The read
syscall itself should be enforcing POSIX conformance regardless of how
the underlying driver behaves.

> Also, the system calls for which SA_RESTART is effective seems
> to change over time, e.g. before 2.6.22 futex(),
> sem_wait and sem_timedwait() did not observe SA_RESTART.
> (There's about a page listing various syscall's behaviour
> with SA_RESTART in TLPI book.)

Yes, that was a serious bug. Thankfully it's been fixed, and there are
enough other relatively important fixes around the same time that it's
a really bad idea to be using such an old kernel for applications that
use threads.


More information about the uClibc mailing list