Re: kern/57171: altqd takes 100% of a CPU when daemon is stopped

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/57171; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57171: altqd takes 100% of a CPU when daemon is stopped
Date: Sat, 07 Jan 2023 04:18:32 +0700

     Date:        Fri,  6 Jan 2023 19:30:02 +0000 (UTC)
     From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
     Message-ID:  <20230106193002.6D4751A923A%mollari.NetBSD.org@localhost>
 
   |  1. When altqd is hanging and taking 100% CPU, hit ^T at the terminal
   |     and show what it prints?
 
 Unless altqd is running in the same process group as the terminal (which
 seems unlikely for a daemon started by rc.d scripts) that isn't going to
 help.
 
   |  It might be stuck in logic in userland.
 
 From the output shown, that's almost certain (no kernel stack backtrace
 is possible, as there's no kernel stack at the time).
 
   | Possible there's some bug with the data structure management
   | in qop.c that sends it into an infinite loop.
 
 Seems plausible, qop_clear() (where things are being stuck, apparently)
 has 2 loops, neither of which is manifestly certain to terminate, though
 what actually happens depends upon what is actually in the lists being
 manipulated.
 
 But in the output interface case, if every element on the list has a
 child, then nothing happens, the list will never change, and hence
 never become empty, and thus, the code will loop forever.  But of course,
 only if every entry on the list has a child, if that's impossible, then
 each iteration must delete something.
 
 For the input interface case, there's a similar potential problem, if
 nothing on the list has a parent that is root, and root has no child,
 then nothing changes, and if the list is not empty, it will loop forever.
 Again, I have no idea if this is possible.   [Also, to me, the
 qop_delete_class(root) inside the while(!LIST_EMPTY()) loop looks
 very suspicious.]
 
 kre