Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Dec 2004 00:03:17 +0200
From:      "Oleg V. Nauman" <oleg@reis.zp.ua>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        freebsd-bugs@FreeBSD.org
Subject:   Re: bin/75258: [patch] dd(1) has not async signal safe interrupt handlers
Message-ID:  <20041227220317.GK76703@core.zp.ua>
In-Reply-To: <20041224014730.R73904@delplex.bde.org>
References:  <200412191530.iBJFUPXC079591@freefall.freebsd.org> <20041224014730.R73904@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--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--



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