Flow timeout timing/v14 #12084
Flow timeout timing/v14 #12084
Conversation
When a thread fails to spawn, include the thread name in the error message.
No longer init then deinit part of the engine at startup of the unix socket mode.
Timeout checks would access certain fields w/o locking, which could lead to thread safety issues.
Use a more precise calculation for timing out flows, using both the seconds and the micro seconds.
The flow worker needs to get the opportunity to run the flow update before globally making it's current timestamp available. This is to avoid another thread using the time to evict the flow that is about to get a legitimate update.
If seconds match a flow can still be timing out.
When timing out flows, use the timestamp from the "owning" thread. This avoids problems with threads being out of sync with each other.
As this may mean that a threads ts is a bit ahead of the minimum time the flow manager normally uses, it can evict flows a bit faster.
The idea of sealing the thread store is that its members can be accessed w/o holding a lock to the whole store at runtime.
Some checks can be done w/o holding a lock: - seeing if the flow matches the packet - if the hash row needs a timeout check This patch skips taking a lock in these conditions.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #12084 +/- ##
==========================================
- Coverage 83.42% 83.36% -0.07%
==========================================
Files 910 910
Lines 257642 257611 -31
==========================================
- Hits 214949 214747 -202
- Misses 42693 42864 +171
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Information: ERROR: QA failed on SURI_TLPW2_autofp_suri_time. ERROR: QA failed on SURI_TLPR1_alerts_cmp.
Pipeline 23246 |
|
Passed my QA. Ran this PR with SV PR OISF/suricata-verify#2116. Local pipeline 5127, run 623. |
Interesting deviations. I think I can explain the change in flow count and alert count theoretically. But, refraining from verifying until I get a response on the questions above. |
|
Information: ERROR: QA failed on SURI_TLPW2_autofp_suri_time. ERROR: QA failed on SURI_TLPR1_alerts_cmp.
Pipeline 23250 |
| @@ -157,6 +157,7 @@ static OutputInitResult EveStreamLogInitCtxSub(ConfNode *conf, OutputCtx *parent | |||
| ctx->trigger_flags |= SetFlag(conf, "state-update", STREAM_PKT_FLAG_STATE_UPDATE); | |||
| ctx->trigger_flags |= | |||
| SetFlag(conf, "spurious-retransmission", STREAM_PKT_FLAG_SPURIOUS_RETRANSMISSION); | |||
| ctx->trigger_flags |= SetFlag(conf, "tcp-port-reuse", STREAM_PKT_FLAG_TCP_PORT_REUSE); | |||
There was a problem hiding this comment.
Q: Why is it called "port" reuse?
| @@ -182,16 +185,20 @@ void FlowDisableFlowManagerThread(void) | |||
| */ | |||
| static bool FlowManagerFlowTimeout(Flow *f, SCTime_t ts, uint32_t *next_ts, const bool emerg) | |||
| { | |||
| uint32_t flow_times_out_at = f->timeout_at; | |||
| SCTime_t timesout_at; // = f->lastts; | |||
| /* update time */ | ||
| if (!(PKT_IS_PSEUDOPKT(p))) { | ||
| TimeSetByThread(tv->id, p->ts); | ||
| } | ||
|
|
There was a problem hiding this comment.
Could we merge it w the else if condition above?
| @@ -2266,7 +2266,7 @@ void TmThreadsGetMinimalTimestamp(struct timeval *ts) | |||
| if (t->type != TVT_PPT) | |||
| continue; | |||
| if (SCTIME_CMP_NEQ(t->pktts, nullts)) { | |||
| SCTime_t sys_sec_stamp = SCTIME_ADD_SECS(t->sys_sec_stamp, 1); | |||
| if (TimeModeIsLive()) { | ||
| if (SCTIME_CMP_LT(pktts, timesout_at)) { | ||
| return false; | ||
| } | ||
| } else { | ||
| if (ftid == f->thread_id[0] || f->thread_id[0] == 0) { | ||
| /* do the timeout check */ | ||
| if (SCTIME_CMP_LT(pktts, timesout_at)) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
We seem to do the same thing in both the blocks? Can we merge them? Then it becomes similar to flow manager..
More precise flow timeout enforcement.
Cleans up unix socket initialization.
SV_BRANCH=OISF/suricata-verify#2116