Subject: Re: gif can cause kernel to hang
To: Jeff Rizzo <riz@boogers.sf.ca.us>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-net
Date: 02/10/2004 16:18:32
> Ah HAH. Once I managed to get this working directly with gifnetisr(),
> it was enlightening... because the problem DOESN'T HAPPEN.
> Instead, it logs this message to console:
>
> Feb 10 20:56:52 /netbsd: gif_output: recursively called too many times(2)
>
> ...which I wondered about the first time I looked in if_gif.c;
> it's clear someone already thought of this, and set up some
> recursion detection to avoid it. Apparently, this detection doesn't
> work with the interrupt deferred. I'll look into this a little further...
That's exactly what I expected from reading the code, but it's nice to
have confirmation.
Since we no longer have a single call chain with the deferred soft
interrupts, we need to bundle a closure with a binding to the static
variable, perhaps using an extension of Jonathan Stone's continuations.
(define (soft-intr-thunk)
(let
((giflevel 0))
(lambda ()
[do-soft-intr code that refers to giflevel])))
But seriously, one could try to attach some sort of 'gif-level'
property to the mbuf and have gif_output increment that. This seems
pretty gross, but the original nesting detection is also bit of a
kludge. And, as the comment says, it was never MP-safe.
Perhaps we should consider not using deferred interrupts on gifs as an
interim measure.