Project

General

Profile

Actions

Bug #3700

closed

nfs: post-GAP file handling

Added by Victor Julien over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
Needs backport to 4.1, Needs backport to 5.0

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 5 (1 open4 closed)

Related to Suricata - Bug #3375: Tracking: file tracking/inspection performance issuesNewVictor JulienActions
Related to Suricata - Bug #3425: nfs: post-GAP file tx handlingClosedVictor JulienActions
Copied from Suricata - Bug #3699: smb: post-GAP file handlingClosedVictor JulienActions
Copied to Suricata - Bug #3788: nfs: post-GAP file handlingClosedJeff LucovskyActions
Copied to Suricata - Bug #3789: nfs: post-GAP file handlingClosedShivani BhardwajActions
Actions

Also available in: Atom PDF