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.