-
Notifications
You must be signed in to change notification settings - Fork 1.6k
engine/mt: Ensure master lock held for reload #13992
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
c6ae82c
to
e94440e
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #13992 +/- ##
========================================
Coverage 83.86% 83.87%
========================================
Files 1011 1011
Lines 275556 275677 +121
========================================
+ Hits 231107 231228 +121
Misses 44449 44449
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Information: QA ran without warnings. Pipeline = 27926 |
Issue: 7819 DetectEngineReload must hold the `master->lock`; recent changes changed the locking usages to avoid deadlock when registering/handling tenants. These changes added the presumption that the master lock is held at a higher level. Coverity highlighted that the lock is not held consistently.
Information: QA ran without warnings. Pipeline = 27931 |
Information: QA ran without warnings. Pipeline = 27935 |
Add a DBV assert to validate that the master->lock is held. Suppress missing master->lock warning Issue: 7819
Information: QA ran without warnings. Pipeline = 27945 |
Passed my QA. Ran this PR with SV master. Local pipeline 5763, run 1046. |
Continuation of #13739
Issue: 7819
DetectEngineReload must hold the
master->lock
; recent changes changed the locking usages to avoid deadlock when registering/handling tenants. These changes added the presumption that the master lock is held at a higher level. Coverity highlighted that the lock is not held consistently.Link to ticket: https://redmine.openinfosecfoundation.org/issues/7819
Describe changes:
Update
SCMutexIsLocked
SCMutexIsLocked
under DBV to assertmaster->lock
heldSCMutexIsLocked
Provide values to any of the below to override the defaults.
link to the pull request in the respective
_BRANCH
variable.SV_REPO=
SV_BRANCH=
SU_REPO=
SU_BRANCH=