Date: Sat, 01 Sep 2007 11:33:02 -0400 From: Joe Marcus Clarke <marcus@FreeBSD.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: freebsd-arch@FreeBSD.org Subject: Re: Understanding interrupted system calls Message-ID: <1188660782.41727.5.camel@shumai.marcuscom.com> In-Reply-To: <20070901112600.GA33832@stack.nl> References: <1188600721.1255.11.camel@shumai.marcuscom.com> <20070901112600.GA33832@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-ZZaeLCSTA/pFm7KdVpbu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2007-09-01 at 13:26 +0200, Jilles Tjoelker wrote: > On Fri, Aug 31, 2007 at 06:52:01PM -0400, Joe Marcus Clarke wrote: > > In my attempts to debug the problems with ConsoleKit and the > > VT_WAITACTIVE ioctl, I delved into the tsleep/msleep code, and I think = I > > have a pretty good idea when it returns EINTR vs. ERESTART. However, > > I'm curious as to why I have to do something like the following to allo= w > > a process waiting in tsleep() to die when it receives a termination > > signal (e.g. SIGTERM or SIGINT): > >=20 > > struct sigaction sa; > >=20 > > sa.sa_handler =3D SIG_DFL; > > ... > > sigaction (SIGTERM, &sa, NULL); > >=20 > > Shouldn't the ps_sigintr set be initialized to the default set of > > termination signals by default (e.g. in init_main.c proc0_init())? Tha= t > > is, shouldn't the list of signals whose default action is to terminate > > the process (according to signal(3)) be allowed to interrupt a system > > call by default? If one then wants to restart the syscall, they can > > explicitly do: >=20 > > struct sigaction sa; >=20 > > sa.sa_flags =3D SA_RESTART; > > ... > > sigaction (SIGTERM, &sa, NULL); >=20 > > I'm just trying to get a better handle on why terminating a program tha= t > > is running the VT_WAITACTIVE ioctl leaves an unkillable process on > > FreeBSD, but apparently just causes the program to terminate on Linux. >=20 > The problem seems to be the following code in > src/sys/dev/syscons/syscons.c, in case VT_WAITACTIVE in scioctl(): >=20 > while ((error=3Dtsleep(&scp->smode, PZERO|PCATCH, > "waitvt", 0)) =3D=3D ERESTART) ; >=20 > If a signal is caught and system call restart is enabled for that > signal, this makes it spin in a tight loop, waiting in vain for the > signal to go away. The idea of ERESTART is that the syscall function > returns it and then the signal handler is entered. If and when the > signal handler returns, it will return to the system call instruction, > restarting it (perhaps this is optimized to avoid the switch to userland > and back). With EINTR, the signal handler would return to directly > after the system call instruction. >=20 > The fixed version would then be >=20 > error =3D tsleep(&scp->smode, PZERO|PCATCH, "waitvt", 0); >=20 > I have not tested this, however. >=20 > The VT_WAITACTIVE implementation in pcvt > (src/sys/i386/isa/pcvt/pcvt_ext.c) appears to have the same issue (in > RELENG_6; pcvt has been removed from HEAD). I read the code the same way, but being naive in this area, assumed that's how the syscall would get restarted. The way you just described does make much more sense, and also seems to be the way other instances of tsleep() work. However, I'm curious as to my other point in this thread. Why should one need to re-register the default signal handlers to get a syscall to return EINTR? Or should ERESTART be caught and turned into EINTR then return to the caller (as in kern_connect())? Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-ZZaeLCSTA/pFm7KdVpbu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBG2YYqb2iPiv4Uz4cRAt6LAJ9DoqnwGa83onXMS3GMAsInc9Nq8wCeJnuB 7YL7sC0EE6pUkfAgPoi2v30= =vug/ -----END PGP SIGNATURE----- --=-ZZaeLCSTA/pFm7KdVpbu--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1188660782.41727.5.camel>