>        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*.

That's a bug, and *your own CVS commit message* confirms that you
checked in an ad-hoc workaround.  you please confirm that you have
understoond that point? I take it as read that you will refrain from
commititng ad-hoc workarounds in future.


[*] The code I have has some minor differences from the netipsec/
code, but none of those are in pf_key handling.