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
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
