Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 5 Jun 2002 12:34:34 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        "Todd C. Miller" <Todd.Miller@courtesan.com>
Cc:        Garance A Drosihn <drosih@rpi.edu>, Alexander Leidinger <netchild@FreeBSD.ORG>, <audit@FreeBSD.ORG>
Subject:   Re: [PATCH] making dump EINTR resistant 
Message-ID:  <20020605121248.U5878-100000@gamplex.bde.org>
In-Reply-To: <200206050110.g551Alpu020379@xerxes.courtesan.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Jun 2002, Todd C. Miller wrote:

> In message <p05111726b923006f0c07@[128.113.24.47]>
> 	so spake Garance A Drosihn (drosih):
>
> > Would it be acceptable to add EINTR-type checks to freebsd-ish
> > code?  There are some sections of lpr/lpd which do not work
> > right when compiled on other platforms, unless I add EINTR
> > checks at the right places.

This would probably be a lot of work.  You would have to check for
EINTR after every syscall that may set EINTR and somehow handle this
non-error.

> It would probably be better to just make the code in question to
> just use sigaction() if you are concerned about portability.  That
> way you get consistent handling of syscall restarts.

I agree, but not that SA_RESTART wasn't portable until tomorrow (sic),
since it is in POSIX.1-2001 but not in older POSIXes (.1-1996 at least).

> Alternately, you could #define signal to bsd_signal when compiling
> on non-BSD platforms.  That is not quite as portable though.

POSIX.1-2001 even has bsd_signal() as standard.

BTW:
(1) stdio doesn't check for EINTR, so it's not clear how it can work
    right if en application enables EINTR using siginterrupt(3) or
    sigaction(2).  Working right includes restarting writes from
    deep in fprintf() just like the kernel would do.
(2) Interactive applications that catch signals using non-broken
    signal handlers ought to enable EINTR so that signals can break
    them out of blocked read(2)'s, etc.  Ones that have had their
    signal handlers fixed to not do unsafe things tend to get this
    wrong.  E.g., top(1) can't be killed by SIGINT when in command
    mode (you have to enter a newline to finish the read).

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020605121248.U5878-100000>