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

output-json: drop eve records that are too long #12165

Closed
wants to merge 2 commits into from

Conversation

jasonish
Copy link
Member

@jasonish jasonish commented Nov 27, 2024

  • output-json: drop eve records that are too long
    In the situation where the mem buffer cannot be expanded to the
    requested size, drop the log message.

    For each JSON log context, a warning will be emitted once with a partial
    bit of the log record being dropped to identify what event types may be
    leading to large log records.

    This also fixes the call to MemBufferExpand which is supposed be
    passed the amount to expand by, not the new size required.

    Ticket: https://redmine.openinfosecfoundation.org/issues/7300

  • output-json: cleanup, have OutputJsonBuilderBuffer return void
    The return value was never used.

In the situation where the mem buffer cannot be expanded to the
requested size, drop the log message.

For each JSON log context, a warning will be emitted once with a partial
bit of the log record being dropped to identify what event types may be
leading to large log records.

This also fixes the call to MemBufferExpand which is supposed be
passed the amount to expand by, not the new size required.

Ticket: OISF#7300
@jasonish jasonish changed the title 7300/too long json/v1 output-json: drop eve records that are too long Nov 27, 2024
Copy link

codecov bot commented Nov 27, 2024

Codecov Report

Attention: Patch coverage is 22.22222% with 7 lines in your changes missing coverage. Please review.

Project coverage is 49.83%. Comparing base (bd7d38e) to head (6ce0cb3).

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #12165      +/-   ##
==========================================
+ Coverage   49.81%   49.83%   +0.02%     
==========================================
  Files         909      909              
  Lines      257904   257911       +7     
==========================================
+ Hits       128467   128542      +75     
+ Misses     129437   129369      -68     
Flag Coverage Δ
fuzzcorpus 60.99% <22.22%> (+0.04%) ⬆️
livemode 19.43% <0.00%> (+<0.01%) ⬆️
pcap 44.40% <0.00%> (-0.02%) ⬇️
suricata-verify 62.72% <22.22%> (-0.02%) ⬇️
unittests 8.98% <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 23585

@@ -981,13 +981,23 @@ int OutputJsonBuilderBuffer(
size_t jslen = jb_len(js);
DEBUG_VALIDATE_BUG_ON(jb_len(js) > UINT32_MAX);
if (MEMBUFFER_OFFSET(*buffer) + jslen >= MEMBUFFER_SIZE(*buffer)) {
MemBufferExpand(buffer, (uint32_t)jslen);
size_t expand_by = MEMBUFFER_OFFSET(*buffer) + jslen + 1;
Copy link
Member

Choose a reason for hiding this comment

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

git message says "This also fixes the call to MemBufferExpand which is supposed be
passed the amount to expand by, not the new size required." , however it seems the opposite happens here: total is passed.

Wonder if we should just grow to a next multiple of 4k (or PAGESIZE) that fits

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