From owner-freebsd-audit Wed Jun 5 13:39:29 2002 Delivered-To: freebsd-audit@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id B404037B40F; Wed, 5 Jun 2002 13:39:25 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id GAA12476; Thu, 6 Jun 2002 06:39:11 +1000 Date: Thu, 6 Jun 2002 06:43:03 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alexander Leidinger Cc: netchild@FreeBSD.ORG, , Subject: Re: [PATCH] making dump EINTR resistant In-Reply-To: <200206050819.g558JnPP000786@Magelan.Leidinger.net> Message-ID: <20020606063157.V8685-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 5 Jun 2002, Alexander Leidinger wrote: > On 5 Jun, Bruce Evans wrote: > > read(), etc., are supposed to be restarted after signals, so the EINTR > > checks should have no effect in most cases. > > Yes, I wanted to handle it with sigaction & SA_REASTART, but the APUE > book teached me, that signal(3) does restart interrupted syscalls by > default on 4.3(+)BSD. Therefore I handled it with do-while code. > > Stevens lists only ioctl, read, readv, write, writev, wait and waitpid, > but not open, fopen, close and fclose. What about those? Stevens is correct, but in practice open() and close() often ignores signals while it is in the kernel, so signal delivery occurs when the process is about to leave the kernel and doesn't result in the syscall returning EINTR. I think this (no EINTR) happens for regular files and disk devices. It doesn't happen for slow devices like terminals, and shouldn't happen if the syscall can block (then the device driver must support the syscall being aborted by a signal). fopen() and fclose() are based on open() and close(), and hopefully don't make any other syscalls that could affect this. (POSIX more or less specifies no surprises here.) Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message