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: matt@3am-software.com
3am Software Foundry              www: 
http://3am-software.com/bio/matt/ Cupertino, CA              
disclaimer: I avow all knowledge of this message.