Project

General

Profile

Actions

Bug #3788

closed

nfs: post-GAP file handling

Added by Jeff Lucovsky over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
High
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

The issue addressed in #3425 is not completely fixed. The transactions are cleaned up properly, however the files are not.

As the files list and the transactions are only loosely connected, the files need to be explicitly handled. Transactions are freed based on their "progress", files based on their "state". If the "state" stays "FILE_STATE_OPEN", the file won't be freed until the end of the flow. The post-GAP handling doesn't explicitly change the file state and therefore the file is not freed. This can lead to a situation where the file list contains an ever increasing amount of "open" files that are never freed or otherwise used, but do consume memory and slow down various operations that walk the file list.

Making things worse is the feedback loop of these nfs sessions becoming ever more expensive, leading the pkt loss, contributing to more of these "dangling" files, leading to more loss, etc.


Related issues 1 (0 open1 closed)

Copied from Suricata - Bug #3700: nfs: post-GAP file handlingClosedVictor JulienActions
Actions #1

Updated by Jeff Lucovsky over 4 years ago

  • Copied from Bug #3700: nfs: post-GAP file handling added
Actions #2

Updated by Jeff Lucovsky over 4 years ago

  • Status changed from Assigned to In Review
Actions #4

Updated by Jeff Lucovsky about 4 years ago

  • Status changed from In Review to Closed
Actions

Also available in: Atom PDF