Skip to content
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

Datasets locking/v5 #12334

Closed
wants to merge 2 commits into from
Closed

Conversation

inashivb
Copy link
Member

@inashivb inashivb commented Jan 3, 2025

Link to ticket: https://redmine.openinfosecfoundation.org/issues/7398

Previous PR: #12326

Changes since v4:

  • error on mixing dataset and datarep values
  • rustfmt on datasets.rs

Note: This introduces a change in behavior for the case when one or more datasets read from a specific file were not added to the hash for some reason.

option value master this branch
init-errors-fatal true error error
init-errors-fatal false skip over this dataset error

Q: Wdyt about this change in behavior? I do not understand why we'd want to allow adding partial datasets from a file..

In a recent warning reported by scan-build, datasets were found to be
using a blocking call in a critical section.

datasets.c:187:12: warning: Call to blocking function 'fgets' inside of critical section [unix.BlockInCriticalSection]
  187 |     while (fgets(line, (int)sizeof(line), fp) != NULL) {
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
datasets.c:292:12: warning: Call to blocking function 'fgets' inside of critical section [unix.BlockInCriticalSection]
  292 |     while (fgets(line, (int)sizeof(line), fp) != NULL) {
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
datasets.c:368:12: warning: Call to blocking function 'fgets' inside of critical section [unix.BlockInCriticalSection]
  368 |     while (fgets(line, (int)sizeof(line), fp) != NULL) {
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
datasets.c:442:12: warning: Call to blocking function 'fgets' inside of critical section [unix.BlockInCriticalSection]
  442 |     while (fgets(line, (int)sizeof(line), fp) != NULL) {
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
datasets.c:512:12: warning: Call to blocking function 'fgets' inside of critical section [unix.BlockInCriticalSection]
  512 |     while (fgets(line, (int)sizeof(line), fp) != NULL) {
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5 warnings generated.

These calls are blocking in the multi tenant mode where several tenants
may be trying to load the same dataset in parallel.
In a single tenant mode, this operation is performed as a part of a
single thread before the engine startup.

In order to evade the warning and simplify the code, the initial file
reading is moved to Rust with this commit with a much simpler handling
of dataset and datarep.

Bug 7398
Copy link

codecov bot commented Jan 3, 2025

Codecov Report

Attention: Patch coverage is 83.92857% with 9 lines in your changes missing coverage. Please review.

Project coverage is 83.24%. Comparing base (6f937c7) to head (0f6b761).
Report is 23 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #12334      +/-   ##
==========================================
- Coverage   83.26%   83.24%   -0.02%     
==========================================
  Files         912      913       +1     
  Lines      257643   257651       +8     
==========================================
- Hits       214521   214479      -42     
- Misses      43122    43172      +50     
Flag Coverage Δ
fuzzcorpus 61.22% <42.85%> (+0.08%) ⬆️
livemode 19.42% <0.00%> (+0.02%) ⬆️
pcap 44.42% <0.00%> (+<0.01%) ⬆️
suricata-verify 62.88% <83.92%> (+0.02%) ⬆️
unittests 59.19% <0.00%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 24062

@victorjulien
Copy link
Member

Q: Wdyt about this change in behavior? I do not understand why we'd want to allow adding partial datasets from a file..

What is the reason for doing this change as part of these commits? Seems like a behavior change should have its own commit?

@inashivb
Copy link
Member Author

inashivb commented Jan 6, 2025

Q: Wdyt about this change in behavior? I do not understand why we'd want to allow adding partial datasets from a file..

What is the reason for doing this change as part of these commits? Seems like a behavior change should have its own commit?

FatalErrorOnInit is not available on the Rust side and uses an atomic var on the C side. That's where the behavior change comes from. I thought of trying to understand and moving this to Rust but wasn't sure of the schemes I came up with and I couldn't understand why we use it in the first place on the C side. Lmk wdyt?

@victorjulien
Copy link
Member

Q: Wdyt about this change in behavior? I do not understand why we'd want to allow adding partial datasets from a file..

What is the reason for doing this change as part of these commits? Seems like a behavior change should have its own commit?

FatalErrorOnInit is not available on the Rust side and uses an atomic var on the C side. That's where the behavior change comes from. I thought of trying to understand and moving this to Rust but wasn't sure of the schemes I came up with and I couldn't understand why we use it in the first place on the C side. Lmk wdyt?

It is used to for errors to be fatal on initial startup, but not be fatal during a rule reload. We need it to stay as is. I think the simplest think to do would be to have a C helper func that you can expose to Rust, hiding the implementation details like an atomic.

@inashivb
Copy link
Member Author

inashivb commented Jan 6, 2025

Q: Wdyt about this change in behavior? I do not understand why we'd want to allow adding partial datasets from a file..

What is the reason for doing this change as part of these commits? Seems like a behavior change should have its own commit?

FatalErrorOnInit is not available on the Rust side and uses an atomic var on the C side. That's where the behavior change comes from. I thought of trying to understand and moving this to Rust but wasn't sure of the schemes I came up with and I couldn't understand why we use it in the first place on the C side. Lmk wdyt?

It is used to for errors to be fatal on initial startup, but not be fatal during a rule reload. We need it to stay as is. I think the simplest think to do would be to have a C helper func that you can expose to Rust, hiding the implementation details like an atomic.

Thank you very much. Hadn't considered the reloads. 🙇🏽‍♀️

Copy link
Member

@victorjulien victorjulien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see inline

rust/src/detect/datasets.rs Show resolved Hide resolved
rust/src/detect/datasets.rs Show resolved Hide resolved
rust/src/detect/datasets.rs Show resolved Hide resolved
rust/src/detect/datasets.rs Show resolved Hide resolved
rust/src/detect/datasets.rs Show resolved Hide resolved
rust/src/detect/datasets.rs Show resolved Hide resolved
@inashivb inashivb mentioned this pull request Jan 9, 2025
@inashivb inashivb closed this Jan 9, 2025
@inashivb inashivb deleted the datasets-locking/v5 branch January 9, 2025 06:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants