From owner-freebsd-stable@FreeBSD.ORG Thu Mar 17 16:58:27 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA2C16A4CE; Thu, 17 Mar 2005 16:58:27 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3946C43D2D; Thu, 17 Mar 2005 16:58:27 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] (sam@[66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j2HGwPms009441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Mar 2005 08:58:26 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4239B796.80303@errno.com> Date: Thu, 17 Mar 2005 09:00:06 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <6.2.1.2.0.20050315112131.054b56f8@64.7.153.2> <4237523B.7090005@errno.com> <4238782A.7010606@errno.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org Subject: Re: RELENG_5 and FAST_IPSEC limits X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2005 16:58:27 -0000 Hajimu UMEMOTO wrote: > Hi, > > >>>>>>On Wed, 16 Mar 2005 10:17:14 -0800 >>>>>>Sam Leffler said: > > > sam> Note the change lacks any locking so if your SA db is changing there's a > sam> good chance you'll blow up. > > Ah, yes. I forgot the fact that FAST_IPSEC is mpsafe. > How about this? This is againt sys/netipsec/key.c with my previous > patch applied. > <...patch removed...> Possibly; I can't tell from the patch if locks are held across calls they should not be. I also worry about the effect of holding the various locks for an extended period of time (will it impact packet processing?) Note that switching to a sysctl would also eliminate a problem in the PF_KEY socket code where the raw_cb list is walked w/o holding rawcb_mtx. Roselyn Lee at Vernier Networks hit this but we didn't apply a change she had (yet) because there appeared to be issues with LOR's between the raw cb and SA db locks. In general the PF_KEY code is desparately in need of a rewrite--if for nothing else but to isolate the ABI dependence between PF_KEY and the IPsec code. Been on my TODO list for several years now. Are you suggesting KAME code can/will change to eliminate the use of PF_KEY sockets to query the SA db state? Sam