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_at_FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome