Bug #4078
closedsmb: post-GAP file handling
Description
The issue addressed in #3400 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 smb sessions becoming ever more expensive, leading the pkt loss, contributing to more of these "dangling" files, leading to more loss, etc.