[PATCH 1/1] Fix bugs determining active VT consoles

[Remco Treffkorn]

On Friday 31 August 2007, Joe Marcus Clarke wrote:
> On Fri, 2007-08-31 at 11:33 -0700, Remco Treffkorn wrote:
> > On Friday 31 August 2007, Joe Marcus Clarke wrote:
> > > On Fri, 2007-08-31 at 12:46 -0400, William Jon McCann wrote:
> > > > On 8/31/07, Joe Marcus Clarke <marcus at freebsd.org> wrote:
> > > > > On Fri, 2007-08-31 at 12:22 -0400, William Jon McCann wrote:
> > > > > > On 8/30/07, Joe Marcus Clarke <marcus at freebsd.org> wrote:
> > > > > > > On FreeBSD, having a process sit in VT_WAITACTIVE can cause
> > > > > > > kernel panics or unkillable processes that consume 100% of the
> > > > > > > CPU.  To work around this problem, replace the model where
> > > > > > > individual threads call VT_WAITACTIVE with a g_timeout model
> > > > > > > which checks the active VT every second, and queues an event
> > > > > > > when it changes.
> > > > > >
> > > > > > As I said in the other mail, I don't think we want to do this. 
> > > > > > Can you describe why you think this isn't a FreeBSD kernel bug?
> > > > >
> > > > > I missed the other email, sorry.  From my reading of what this
> > > > > ioctl is supposed to do, it is typically called after activating a
> > > > > given VT to ensure that the VT is active before proceeding.  It
> > > > > should not be something a program sits in for long periods of time.
> > > >
> > > > According to what or whom?
> > >
> > > I read it from Linux Journal:
> > >
> > > http://www.linuxjournal.com/article/2783
> > >
> > > That made me think it's used more to see if the switch is complete than
> > > as an event driver.
> >
> > This article is from 1994! Nowhere does it indicate a problem with
> > VT_WAITACTIVE.
>
> No, but it indicates that the purpose of VT_WAITACTIVE is to wait for a
> VT switch to complete.

Right.

> > How does this relate to FreeBSD and a potential problem there?
>
> I already described the real problem with a process hanging on shutdown
> because the threads are waiting for VT_WAITACTIVE to return.

If by this you mean:

"
On FreeBSD, having a process sit in VT_WAITACTIVE can cause kernel panics or 
unkillable processes that consume 100% of the CPU.  To work around this 
problem, replace the model where
"

The the only thing I have to say is: This is a severe kernel bug. An 
unprivileged user space program can crash the system. There aren't any bugs 
more severe than that.

> > Could you please explain what makes you think there is a FreeBSD bug that
> > makes VT_WAITACTIVE risky to use, and why you think working around a
> > problem is better than fixing it?
>
> I already sent email out to kernel developers, but I haven't heard back.
> Something needs to be done, and instead of sitting on my ass, I decided
> to take some initiative based on what I found on the web.

If you are correct, and FreeBSD kernel panics on the use of VT_WAITACTIVE when 
the process gets SIGTERM (or others), then the correct reaction would be:

   1. Disable this ioctl in the kernel. Just have it fail immediately.

   2. Now fix the behavior and re-enable the ioctl.

The correct behavior for any blocking system calls is to return the error 
EAGAIN when the process receives a signal.

I just have an extremely hard time believing that the BSD developers would be 
cavalier about a bug with that severity.

If you think you have found a bug, please keep pushing it with the developers.

Cheers,
Remco

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco at rvt.com   (831) 685-1201