From owner-freebsd-questions  Sun Sep 22 11:52:37 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id LAA29301
          for questions-outgoing; Sun, 22 Sep 1996 11:52:37 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA29275
          for <freebsd-questions@freebsd.org>; Sun, 22 Sep 1996 11:52:34 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id NAA04002; Sun, 22 Sep 1996 13:52:09 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199609221852.NAA04002@dyson.iquest.net>
Subject: Re: systat/netstat utilities buggy?
To: pjchilds@imforei.apana.org.au (Peter Childs)
Date: Sun, 22 Sep 1996 13:52:09 -0500 (EST)
Cc: brett@lariat.org, freebsd-questions@freebsd.org
In-Reply-To: <199609221819.DAA09508@al.imforei.apana.org.au> from "Peter Childs" at Sep 23, 96 03:49:56 am
Reply-To: dyson@freebsd.org
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> : I would be VERY surprised, though, if a programmer were careless enough to
> : traverse a linked list whose links could potentially change without locking
> : resources -- or deferring insertions and deletions until after a traversal.
> : Doing nameserver lookups in the MIDDLE of the traversal is EXTREMELY poor
> : practice, since it maximizes the danger of inconsistencies even if the list
> : is traversed safely. Do you have the code to FreeBSD's netstat? (I don't
> : have room for the source tree here.) Is it really coded this badly?
> 
>  Grin.. better lock the kernel from opening/closing sockets during
>  a user-land program run?  Nah.. don't think so :)  I'm not sure
>  how netstat works, but a quick look at the code and you should
>  be able to identify the problem.
> 
>  You might need to do a quick dump copy of the table to local
>  land before trying to do any action (ie. the current system might
>  be trying to do hostname resolution whilst traversing the
>  list)
> 
>  Good luck and don't forget to submit your diffs :)
> 
The whole historical paradigm of peeking into the kernel is 
mostly flawed.  That is going away slowly with procfs/sysctl/etc...

John