Re: VT_WAITACTIVE leads to unkillable processes

On Wed, 2007-08-29 at 19:37 -0400, Joe Marcus Clarke wrote:
flz and I are working on a port of ConsoleKit to FreeBSD. ConsoleKit is
a framework for tracking local users (i.e. users sitting at a machine)
and their sessions.

Since it tracks local users and their consoles, it makes generous use of
consio. One of the things it does is get a list of the total number of
available consoles (i.e. vtys) and starts a thread for each one to check
when the console becomes active. To do this, each thread invokes the
VT_WAITACTIVE ioctl, and sits in waitvt until its vty becomes active.
This works quite well.

Where things break down is when the ConsoleKit daemon is stopped. When
the daemon receives a signal, it immediately jumps to 100% of the CPU
and claims to be in waitvt. It will not die unless you reboot the
machine, or get lucky with the debugger.

Below is a link to a small sample program that will reproduce this
behavior. Simply compile the program, and run it from a vty other than
3 (ttyv2). Then try a control+C, and the problem will appear instantly.

I've been testing 7.0-CURRENT #104: Thu Aug 16 16:54:28 EDT 2007 with
ULE, but I have a report from flz that the same loop is observed on
-STABLE with 4BSD. When I ran the test on -STABLE, my box immediately
panicked, but I did not have dumps setup.

Yes, this is a, "doctor it hurts when I do this" kind of thing; however,
since this does not happen on Linux, I'm wondering if the kernel portion
of the VT_WAITACTIVE ioctl can be modified not to cause this tight loop
(or panic)?

WARNING: This running this program will either cause instance on mostly
unstoppable CPU load on your machine or panic it.

http://www.marcuscom.com/downloads/vty.c

gcc -o vty vty.c
(switch to ttyv0)
./vty

I did some more research into the kernel code, and I found I can
interrupt and terminate the process if I register signal handlers
(simple do-nothing signal handlers) because they populate ps_sigintr.
When ps_sigintr contains the right signal, tsleep() will return EINTR
instead of ERESTART. This seems to be working fine.

Joe

--
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome@xxxxxxxxxxx
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome

Attachment: signature.asc
Description: This is a digitally signed message part