From owner-freebsd-bugs@FreeBSD.ORG Mon Dec 27 22:03:40 2004 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFA9516A4CE for ; Mon, 27 Dec 2004 22:03:40 +0000 (GMT) Received: from core.zp.ua (core.zp.ua [193.108.112.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id B457E43D45 for ; Mon, 27 Dec 2004 22:03:38 +0000 (GMT) (envelope-from oleg@core.zp.ua) Received: from core.zp.ua (oleg@localhost [127.0.0.1]) by core.zp.ua with ESMTPœ id iBRM3LAH082780; Tue, 28 Dec 2004 00:03:21 +0200 (EET) (envelope-from oleg@core.zp.ua)œ Received: (from oleg@localhost) by core.zp.ua id iBRM3H3b082779; Tue, 28 Dec 2004 00:03:17 +0200 (EET) Date: Tue, 28 Dec 2004 00:03:17 +0200 From: "Oleg V. Nauman" To: Bruce Evans Message-ID: <20041227220317.GK76703@core.zp.ua> References: <200412191530.iBJFUPXC079591@freefall.freebsd.org> <20041224014730.R73904@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <20041224014730.R73904@delplex.bde.org> User-Agent: Mutt/1.5.6i cc: freebsd-bugs@FreeBSD.org Subject: Re: bin/75258: [patch] dd(1) has not async signal safe interrupt handlers X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2004 22:03:41 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 24, 2004 at 02:22:19AM +1100, Bruce Evans wrote: > On Sun, 19 Dec 2004, Oleg V. Nauman wrote: >=20 > > On Sun, Dec 19, 2004 at 06:11:06PM +0300, Maxim Konovalov wrote: > > > [...] > > > > >Description: > > > > dd(1) uses not safe interrupt handlers, they may leads to > > > > strange problems with dd > > >=3D20 > > > Are you sure? Do you have a testcase? > > > > No, sorry. >=20 > However, the patch in the PR would cause strange problems like breaking > termination of dd when the input is from certain slow devices, e.g., > terminals. Input is normally restarted after a signal, so just setting > a flag in the signal handler normally doesn't work. Most "fixes" for > unsafe signal handling get this wrong. To get this right, something > like the following must be done: > - use sigaction() without SA_RESTART instead of signal(), or use > siginterrupt() to turn off SA_RESTART. I've only seen this done > right for fixing unsafe signal handling in ping(8) I've seen it > done wrong in top(1) (try hitting ^C in command mode in top). > - handle the resulting EINTR errors from all syscalls that may now > fail with this error instead of being restarted. This is difficult > or impossible in large programs. If the signal is checked for and > acted on after every EINTR, then you have the same problem as acting > on it directly in signal handlers (the syscall might be in a context > that doesn't or shouldn't know if it is safe to act), plus > maintainence problems for checking and acting all over. If the > acton is delayed, then the program must somehow be structured to > ensure that control is passed up to a level that can safely act; > in particular, no more syscalls that might block can be made. I > suppose the latter could be implemented simply but laboriously by > wrapping all syscalls with > { if (signalflag) { errno =3D EINTR; return (-1); } else { normalcall()= ; }. Thank you for your feedback. It looks like I'm could write much more better patch :) >=20 > > >=3D20 > > > > >How-To-Repeat: > > > > > > > > man 2 sigaction > > >=3D20 > > > Well, stdio(3) is not signal-safe in general but it seems for me > > > summary() does not manipulate with the internal state of any file > > > descriptors (it uses write(2)) and should be safe. > > > > But s*printf() family uses malloc(3) for his internal purposes, > > and there is no any reasons for things like memory allocations in > > the signal handler, I think. >=20 > s*printf() needs to be signal-safe in practice. It is careful to use > only local storage for this reason. Only asprintf() uses malloc(). It looks like snprintf() calls __vfprintf(), which calls __wcsconv() and __find_arguments() (/usr/src/lib/libc/stdio/vfprintf.c on my RELENG_5 system) These functions directly calls malloc() (without counts how many calls indirectly) >=20 > summary() is obviously attempting to be signal-safe (even in rev.1.1). > It avoids using printf() but depends on snprintf() being signal safe > since the formatting would be too hard otherwise. >=20 > Bruce --=20 NO37-RIPE --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQCUAwUBQdCGnvC2y8Tb/5DvAQEkqQP48Wx0WkBarimb8nc9rLGfTJXr75mUB5/w fhFHs/OVWO08zFbkKLyY0a3zbzV319excc+uYbQU30ILALptWe4S5gVZ3OReJUTQ yr9s2teXRG74EOvrIECps7PyOS0vSfmjpj0sSyUf2sJcFKOF5rUOROUKPP7F9N9i pLbErmgRXQ== =PF70 -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q--