From owner-freebsd-net@FreeBSD.ORG Mon Jun 25 07:05:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAC3D16A41F for ; Mon, 25 Jun 2007 07:05:48 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (reverse-25.fdn.fr [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id AE82513C468 for ; Mon, 25 Jun 2007 07:05:48 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: by smtp.zeninc.net (smtpd, from userid 1000) id 4E5973F1F; Mon, 25 Jun 2007 09:05:47 +0200 (CEST) Date: Mon, 25 Jun 2007 09:05:47 +0200 From: VANHULLEBUS Yvan To: freebsd-net@freebsd.org Message-ID: <20070625070547.GA24243@zen.inc> References: <467F65A0.9010900@zyxel.com.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467F65A0.9010900@zyxel.com.tw> User-Agent: All mail clients suck. This one just sucks less. Subject: Re: Questions about PF_KEY interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2007 07:05:49 -0000 On Mon, Jun 25, 2007 at 02:50:08PM +0800, blue wrote: > Dear all: Hi. > I found there are two directories about PF_KEY interface: netkey and > netipsec under $FreeBSD src$\sys\. > > Looking into the makefile, the one that is currently used and built in > is netkey. > > However, I am wondering what's the purpose for netipsec? netkey is used if you compile with IPSEC (KAME's stack). netipsec is used if you compile with FAST_IPSEC. > Besides, the handling for the global variable "regtree", which is used > for key registery, in netipsec seems more proper to me. > > For example, when a key is needed to register, the static function, > key_register(), which is defined in [netkey/netipsec]/key.c, will be called. > > However, in netkey/key.c, key_register() will not call mtx_lock before > the operation of the global variable, regtree. On the other hand, in > netipsec/key.c, key_register() will mtx_lock. In my opinion, I think the > latter should be correct since there may be various processes to call > the function. Without the protection, race condition will occur! KAME's IPSec stack is still giant locked, so doesn't needs more fined locking. FAST_IPSEC used fined grain locking. KAME's stack will probably be removed in the future (for 7.0 ?) thanks George V. Neville-Neil's work to provide all KAME's stack features on FAST_IPSEC. Yvan. -- NETASQ http://www.netasq.com