Project

General

Profile

Actions

Bug #512

closed

Bug #540: Multiple issues in defrag code

Fix logic of call to DefragTimeoutTracker()

Added by Eric Leblond over 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
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

Also available in: Atom PDF