From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: System calls interrupted by signals - or not Date: Thu, 1 Feb 2018 01:01:53 +0100 Message-ID: <20180201010153.0c6146f0@scratchpost.org> References: <20180129122403.22184.83539@vcs0.savannah.gnu.org> <20180129122403.D1E1420ABC@vcs0.savannah.gnu.org> <87efm8ojpc.fsf@gnu.org> <20180129150249.7a1a7140@scratchpost.org> <87bmhcbu3e.fsf@netris.org> <20180131003529.03312495@scratchpost.org> <878tcewzbx.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eh2KN-0003jI-Tq for guix-devel@gnu.org; Wed, 31 Jan 2018 19:02:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eh2KI-0006y9-Vp for guix-devel@gnu.org; Wed, 31 Jan 2018 19:02:07 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:46474) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eh2KI-0006x2-OY for guix-devel@gnu.org; Wed, 31 Jan 2018 19:02:02 -0500 In-Reply-To: <878tcewzbx.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org Hi Mark, >This can happen if interrupted by a signal, If only BSD-style signals (SA_RESTART) are used, as is very likely, this should not happen. It only happens with old "PC-losering" style signal handlers - which even signal(2) doesn't install anymore (and I know of no reason why anyone should ever use those). If an OK design limitation is to support only SA_RESTART handlers, I think it suffices to forbid anyone from using msgrcv and msgsnd. That's all. No EINTR loops or buffer position adjustments necessary. Otherwise I made a table some years ago when this bit me, I'll paste it here: Affected Linux syscalls in glibc 2.19 (each lists the newest version only): E futex E semop E semtimedop E pause f ptrace (FIXME) E rt_sigsuspend E T rt_sigtimedwait E sigsuspend E waitid E waitpid E creat E open E openat E B read E B write close (DO NOT retry on EINTR) E U pselect6 E dup E dup2 E dup3 E T epoll_pwait E T epoll_wait E fallocate E fcntl64 E flock E ftruncate64 E truncate64 E T poll E T ppoll E T io_getevents (timeout not modified) (libaio) (only for the direct syscall! otherwise F) E fstatfs64 E statfs64 E accept4 E connect E B recv E B recvfrom E B recvmsg E B send E B sendmsg E B sendto E request_key e t clock_nanosleep E t nanosleep E B t mq_timedreceive E B t mq_timedsend E B msgrcv [IGNORES SA_RESTART] E B msgsnd [IGNORES SA_RESTART] E B preadv E B readv E B pwritev E B writev E U newselect E B getrandom Meaning: E ... returns (-1), sets errno == EINTR e ... returns EINTR directly. f ... returns (-1) whenever it feels like it, but sets errno on errors. F ... returns less than min_nr on error. B ... have to adjust buffer T ... have to adjust timeout. Note that timeout is optional usually. t ... have to adjust timeout, but that's easy. Note that timeout is optional usually. U ... have to adjust timeout, but "timeout is undefined". Note that timeout is optional usually. Note: read() returns EFAULT on SEGV instead of doing SIGSEGV. >or if the file system was full. Yeah, I think I had this too some time ago.