Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Mar 2005 09:00:06 -0800
From:      Sam Leffler <sam@errno.com>
To:        Hajimu UMEMOTO <ume@freebsd.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: RELENG_5 and FAST_IPSEC limits
Message-ID:  <4239B796.80303@errno.com>
In-Reply-To: <ygeis3rbcu7.wl%ume@mahoroba.org>
References:  <6.2.1.2.0.20050315112131.054b56f8@64.7.153.2> <4237523B.7090005@errno.com>	<ygek6o7inb5.wl%ume@mahoroba.org> <4238782A.7010606@errno.com> <ygeis3rbcu7.wl%ume@mahoroba.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hajimu UMEMOTO wrote:
> Hi,
> 
> 
>>>>>>On Wed, 16 Mar 2005 10:17:14 -0800
>>>>>>Sam Leffler <sam@errno.com> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4239B796.80303>