From owner-cvs-all  Wed Jun 20  3: 6:32 2001
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id A320237B403; Wed, 20 Jun 2001 03:06:28 -0700 (PDT)
	(envelope-from brian@FreeBSD.org)
Received: (from brian@localhost)
	by freefall.freebsd.org (8.11.3/8.11.3) id f5KA6Sq43409;
	Wed, 20 Jun 2001 03:06:28 -0700 (PDT)
	(envelope-from brian)
Message-Id: <200106201006.f5KA6Sq43409@freefall.freebsd.org>
From: Brian Somers <brian@FreeBSD.org>
Date: Wed, 20 Jun 2001 03:06:28 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/net if_tun.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

brian       2001/06/20 03:06:28 PDT

  Modified files:
    sys/net              if_tun.c 
  Log:
  Close a race where we were releasing the unit resource at the start
  of tunclose() rather than the end, and tunopen() grabbed that unit
  before tunclose() finished (one process is allocating it while another
  is freeing it!).
  
  It may be worth hanging some sort of rw mutex around all specinfo
  calls where d_close and the detach handler get a write lock and all
  other functions get a read lock.  This would guarantee certain levels
  of ``atomicity'' (is that a word?) that people may expect (I believe
  Solaris does something like this).
  
  Revision  Changes    Path
  1.96      +5 -3      src/sys/net/if_tun.c


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message