DragonFly bugs List (threaded) for 2007-04
DragonFly BSD
DragonFly bugs List (threaded) for 2007-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: [issue599] 1.9.0 reproducable panic

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 12 Apr 2007 10:14:25 -0700 (PDT)

: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.

    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.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]