[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