[issue599] 1.9.0 reproducable panic

[Matthew Dillon]

:On Wed, Apr 11, 2007 at 03:52:30PM -0700, Matthew Dillon wrote:
:>     I'm a bit at a loss a to why netstat -an would trigger the problem,
:>     though.  We do know that anything that accesses /dev/kmem heavily,
:>     like fstat, can crash the machine while chasing down stale pointers
:>     in kernel memory.  But this panic seems a bit at odds with the sort
:>     of crash I would expect from stale pointer chasing.
:
:netstat -an uses a sysctl interface though.
:
:Joerg

    That would make more sense.  I was scratching my head at how a KVM
    access could cause this, a direct sysctl interface is more likely.

    I don't see a whole lot in the sysctl code either, unfortunately.
    e.g. tcp_pcblist() in tcp_subr.c.  There is one likely possibility.
    Because the sysctl is dumping its huge, huge list in one large go
    and holding the big giant lock while it does it, it could be
    preventing the TCP stack's callout's (which is where the panic occured)
    from running during that period.  There could be a race condition there
    that we are not handling properly.

    so, e.g. some sort of race in softclock_handler() in kern_timeout.c
    related to the acquisition of the big giant lock.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>