From owner-freebsd-hackers  Fri Apr  4 14:47:28 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id OAA08594
          for hackers-outgoing; Fri, 4 Apr 1997 14:47:28 -0800 (PST)
Received: from pdx1.world.net (pdx1.world.net [192.243.32.18])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA08589
          for <hackers@freebsd.org>; Fri, 4 Apr 1997 14:47:26 -0800 (PST)
From: proff@suburbia.net
Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with SMTP id OAA01659 for <hackers@freebsd.org>; Fri, 4 Apr 1997 14:49:42 -0800 (PST)
Received: (qmail 7413 invoked by uid 110); 4 Apr 1997 13:14:08 -0000
Message-ID: <19970404131408.7412.qmail@suburbia.net>
Subject: Re: IP Filter in -current.
In-Reply-To: <199704040736.RAA23038@plum.cyber.com.au> from Darren Reed at "Apr 4, 97 05:36:09 pm"
To: darrenr@cyber.com.au (Darren Reed)
Date: Fri, 4 Apr 1997 23:14:07 +1000 (EST)
Cc: darrenr@cyber.com.au, hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> Someone should give this guy a labotamy if he's the one who came up 
> with the "include every other include file in this include file" idea.
> 
> > 	Use of TAILQ's for handling ifaddr chains.
> 
> Is this consistent with NetBSD ?

I'm not sure, but it wasn't consistent with ipfilter :)

Note that the below is a not production; I haven't as yet isolated
the FreeBSD_version when these changes were introduced (so use
>=2).

--- /usr/src/contrib/ipfilter/ip_nat.c	Fri Apr  4 13:07:54 1997
+++ ip_nat.c	Thu Apr  3 05:02:24 1997
@@ -10,8 +12,8 @@
 static	char	rcsid[] = "$Id: ip_nat.c,v 2.0.2.8 1997/04/02 12:23:23 darrenr Exp $";
 #endif
 
+#ifdef IPFILTER_LKM
+#define ACTUALLY_LKM_NOT_KERNEL
 #endif
 
 #if !defined(_KERNEL) && !defined(KERNEL)
@@ -27,6 +27,7 @@
 #include <sys/time.h>
 #include <sys/file.h>
 #include <sys/ioctl.h>
+#include <sys/fcntl.h>
 #include <sys/uio.h>
 #include <sys/protosw.h>
 #include <sys/socket.h>
@@ -42,7 +43,12 @@
 # include <sys/kmem.h>
 #endif
 
+#ifdef __FreeBSD__
+# include <sys/queue.h>
+#endif
+
 #include <net/if.h>
+#include <net/if_var.h>
 #ifdef sun
 #include <net/af.h>
 #endif
@@ -425,15 +431,22 @@
 #else
 				struct ifaddr *ifa;
 				struct sockaddr_in *sin;
-
+# if    __FreeBSD__ >= 2
+				ifa = TAILQ_FIRST(&ifp->if_addrhead);
+# else
 				ifa = ifp->if_addrlist;
+# endif
 # if	BSD < 199306
 				sin = (struct sockaddr_in *)&ifa->ifa_addr;
 # else
 				sin = (struct sockaddr_in *)ifa->ifa_addr;
 				while (sin && ifa &&
 				       sin->sin_family != AF_INET) {
+# if	__FreeBSD__ >=2
+					ifa = TAILQ_NEXT(ifa, ifa_link);
+# else
 					ifa = ifa->ifa_next;
+# endif
 					sin = (struct sockaddr_in *)ifa->ifa_addr;
 				}
 				if (!ifa)


> 
> > 	VOP_LOCK() in lite2 takes three arguments.
> 
> 3 instead of 4 or 3 instead of 2 ?

Three instead of one :)

I'm still not clear if I'm using the correct locking arguments.
mln_ipl.c uses this construct:

	VOP_LOCK(nd.ni_vp);

Which i've turned into:

	VOP_LOCK(nd.ni_vp, LK_INTERLOCK|LK_SHARED, curproc);

Although I feel:

	VOP_LOCK(nd.ni_vp, 0, curproc);

is a more direct translation.

This code is only called when the module is unloaded by hand, and so
far all the module unloading has been courtesy of panic, so testing
opportunities have been limited :)

> > At run-time it seems to panic quickly if logging is going on and
> > ipmon isn't there to read the log device.
> 
> heh...I guess you'll be able to track this bug then :)

I actually strongly suspect my initial views on this were wrong.
The problem doesn't seem to lay with the log buffer filling, but
with the connection state following code, which seems to crash
after a certain period of time (memory?).

Cheers,
Julian.