| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
|
|
|
| |
Instead, log the explicit commands at a higher level.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Uses separate locks for socket read and write operations. While holding the
socket reader lock, a different thread can still claim the socket write lock.
This allows to asynchronously send event messages while holding the read
lock.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Due to an unprotected incrementation, two load-tester initiators occasionally
use the same SPI under high load, and hence generate 2 IPsec SAs with the same
identifier. The responder IPsec stack will refuse to configure the second SA.
Use an atomic incrementation to avoid this race condition.
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
|
|
|
|
|
|
|
|
|
|
| |
Due to an unprotected incrementation, two load-tester initiators occasionally
use the same identifier under high load. The responder typically drops one of
the connections.
Use an atomic incrementation to avoid this race condition.
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Simply using the pointer is not optimal for our hash table
implementation, which simply masks the key to determine the bucket.
|
|
|
|
|
|
| |
accouting updates
Fixes #528.
|
| |
|
| |
|
|
|
|
| |
config
|