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 Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome_at_FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:16 UTC