Actions
Bug #512
closedBug #540: Multiple issues in defrag code
Fix logic of call to DefragTimeoutTracker()
Affected Versions:
Effort:
Difficulty:
Label:
Description
There is a logic problem with the way the DefragTimeoutTracker() function is called.
The only case were this function is called in inside DefragGetTracker()
DefragGetTracker(ThreadVars *tv, DecodeThreadVars *dtv, DefragContext *dc, DefragTracker *lookup_key, Packet *p) { ... tracker = HashListTableLookup(dc->frag_table, lookup_key, sizeof(*lookup_key)); if (tracker == NULL) { SCMutexLock(&dc->tracker_pool_lock); tracker = PoolGet(dc->tracker_pool); if (tracker == NULL) { /* Timeout trackers and try again. */ DefragTimeoutTracker(tv, dtv, dc, p);
When the pool is empty, then we call DefragTimeoutTracker() to do some cleanup. This means we call an intensive function when we are short in ressource.
But the worst is not there, in case of real outage, the function has no locking/concurrency tracking and thus all packet threads call in loop the function to try to find some place.
It would be sane to run the function at a regular interval to avoid: increase in size and problem in case of empty pool.
Actions