Subject: Re: Reminder that we are supporting two parallel IPsec implementations
To: None <email@example.com>
From: Matt Thomas <firstname.lastname@example.org>
Date: 09/11/2003 18:53:14
On Thursday, September 11, 2003, at 05:45 PM, Jonathan Stone wrote:
>> the code is identical in sys/netipsec.
> So if it's identical, you would accept demonstrationn of a bug against
> the sys/netipsec code as applicable to the KAME sys/netkey tree?
> If so,, the bug can be demonstrated quite easily[*]. With
> approximately 340 SAs total, setkey starts returning EAGAIN.
> For racoon, when racoon calls pfkey_dump_sadb(), (e.g., processing a
> new SA) pfke_dump_sadb calls pfkey_recv() to walk through the SA
> database, one SA at a time. Again, at around 340 SAs, the call to
> pfkey_recv() calls recv() which sleeps forever: racoon is deadlocked,
> sleeping inside the kernel in sbwait() where it is never going to be
> woken up.
> Even if I increase ths eize of the raw queue by a factor of 8, this
> behaviour still occurs, and it occurs *at the same number of SAs*.
Note that the kernel *already* has a method to avoid the problem.
netkey should use a PF_KEY specific so_receive to dump the SADB
directly into the users buffer. (check to see if you are doing a
dump and if so, do the uiomoves your self, otherwise just invoke
soreceive to do the heavy lifting).
Matt Thomas email: email@example.com
3am Software Foundry www:
http://3am-software.com/bio/matt/ Cupertino, CA
disclaimer: I avow all knowledge of this message.