From owner-freebsd-bugs  Wed Feb  5 05:30:03 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA14668
          for bugs-outgoing; Wed, 5 Feb 1997 05:30:03 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA14661;
          Wed, 5 Feb 1997 05:30:01 -0800 (PST)
Resent-Date: Wed, 5 Feb 1997 05:30:01 -0800 (PST)
Resent-Message-Id: <199702051330.FAA14661@freefall.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, Jean-Luc.Richier@imag.fr
Received: from tuna.imag.fr (tuna.imag.fr [192.44.68.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA14505
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 5 Feb 1997 05:26:45 -0800 (PST)
Received: (from richier@localhost) by tuna.imag.fr (8.8.3/8.8.3) id OAA00408; Wed, 5 Feb 1997 14:26:01 +0100 (MET)
Message-Id: <199702051326.OAA00408@tuna.imag.fr>
Date: Wed, 5 Feb 1997 14:26:01 +0100 (MET)
From: Jean-Luc.Richier@imag.fr
Reply-To: Jean-Luc.Richier@imag.fr
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: kern/2667: Bug in bpfattach
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         2667
>Category:       kern
>Synopsis:       bpfattach can hang the system
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb  5 05:30:00 PST 1997
>Last-Modified:
>Originator:     Jean-Luc Richier
>Organization:
Institut IMAg, Grenoble, France
>Release:        FreeBSD 2.1.6-RELEASE i386
>Environment:


>Description:

While working on the IPv6 extensions for NetBSD and FreeBSD,
I discovered a problem with bpfattach behaviour. 
If one tries to make extensions to NetBSD, this behaviour raise problems.
Therefore I suggest corrections to the base distribution code.

If the ifattach function is called while a bpf filter is open, the system
hangs.

>How-To-Repeat:

  - Make a modfication in the system which allows to configure a new driver at
    any time (In my case, it is a dynamic modification of the number of IPv6
    tunnel drivers)
  - open bpf filters, for example run ``rarpd -a''
  - configure a new driver
  - some seconds later, the system will hang

>Fix:
Add a static variable to test if it is the first call to bpfattach

*** sys/net/bpf.c.DIST	Sat Jun  8 08:14:15 1996
--- sys/net/bpf.c	Wed Feb  5 11:43:23 1997
***************
*** 1271,1276 ****
--- 1271,1277 ----
  {
  	struct bpf_if *bp;
  	int i;
+ 	static int already = 0;
  #if BSD < 199103
  	static struct bpf_if bpf_ifs[NBPFILTER];
  	static int bpfifno;
***************
*** 1303,1311 ****
  	/*
  	 * Mark all the descriptors free if this hasn't been done.
  	 */
! 	if (!D_ISFREE(&bpf_dtab[0]))
  		for (i = 0; i < NBPFILTER; ++i)
  			D_MARKFREE(&bpf_dtab[i]);
  
  	if (bootverbose)
  		printf("bpf: %s%d attached\n", ifp->if_name, ifp->if_unit);
--- 1304,1314 ----
  	/*
  	 * Mark all the descriptors free if this hasn't been done.
  	 */
! 	if(!already) {
! 		already = 1;
  		for (i = 0; i < NBPFILTER; ++i)
  			D_MARKFREE(&bpf_dtab[i]);
+ 	}
  
  	if (bootverbose)
  		printf("bpf: %s%d attached\n", ifp->if_name, ifp->if_unit);
>Audit-Trail:
>Unformatted: