Previously the flow manager would share evicted flows with the workers
while keeping the flows mutex locked. This reduced the number of unlock/
lock cycles while there was guaranteed to be no contention.
This turns out to be undefined behavior. A lock is supposed to be locked
and unlocked from the same thread. It appears that FreeBSD is stricter on
this than Linux.
This patch addresses the issue by unlocking before handing a flow off
to another thread, and locking again from the new thread.
Issue was reported and largely analyzed by Bill Meeks.
Bug: #4478
(cherry picked from commit
9551cd05357925e8bec8e0030d5f98fd07f17839)
f->fb = NULL;
f->next = NULL;
FlowQueuePrivateAppendFlow(&fls->work_queue, f);
+ FLOWLOCK_UNLOCK(f);
} else {
/* implied: TCP but our thread does not own it. So set it
* aside for the Flow Manager to pick it up. */
FlowForceReassemblyNeedReassembly(f) == 1) {
/* Send the flow to its thread */
FlowForceReassemblyForFlow(f);
+ FLOWLOCK_UNLOCK(f);
/* flow ownership is passed to the worker thread */
- /* flow remains locked */
counters->flows_aside_needs_work++;
continue;
}
RemoveFromHash(f, prev_f);
f->flow_end_flags |= FLOW_END_FLAG_SHUTDOWN;
FlowForceReassemblyForFlow(f);
+ FLOWLOCK_UNLOCK(f);
f = next_f;
continue;
}
{
Flow *f;
while ((f = FlowQueuePrivateGetFromTop(fq)) != NULL) {
+ FLOWLOCK_WRLOCK(f);
f->flow_end_flags |= FLOW_END_FLAG_TIMEOUT; //TODO emerg
const FlowStateType state = f->flow_state;