[Swan-dev] hash table size and hash
Andrew Cagney
andrew.cagney at gmail.com
Mon Oct 30 01:55:46 UTC 2017
FYI,
Really? How many PIDS do we juggle?
With PAM, there's a PID for every opening connection. So "lots".
The state table was scanned only when a loop needed to look at
every state. This could be considered a hack. But it was quite
practical back in the day because it was needed so rarely. Oh, and
the hash table was pretty small.
A review might be useful, but the case I know is deleting a connection.
I'm assuming it is sufficiently rare to not matter.
Andrew also split the cookie-indexed hash table into two. This
means that scanning the one table no longer gets you to all states.
I didn't see that such code was changed to scan both tables.
Perhaps some bugs were created by this split. I have not looked.
This isn't true.
All states always appear in all hash tables so it doesn't matter where you
look; it has been this way for some time. In IKEv2, the responder uses
this to find the state for a duplicate IKEV2 init request - it uses the
icookie table as the icookie+rcookie table is useless.. IKEv1 doesn't do
this and is broken in this regard - the responder, not realising it has
duplicates, creates a new state for every main-mode request it receives.
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20171029/b7e10097/attachment.html>
More information about the Swan-dev
mailing list