We open a new socket every time we want to set the speed of a port, but
never close it. This eventually leads to hitting the maximum amount of
open file descriptors, leading to various other issues.
Fix this by closing the socket on return.
Fixes: b5fe46c ("tap_manager: set port speed on tap interfaces")
Signed-off-by: Jonas Gorski jonas.gorski@bisdn.de
Motivation and Context
Running out of file descriptors breaks STP, since we check sysfs for the stp state of the bridge (which then fails).
How Has This Been Tested?
set one port to up
Run watch'ls -l /proc/pidof baseboxd/fd | wc -l`` on switch
establish link on port
cut link on port
Before:
157 # initial state after boot
211 # port change notification flood after first link change
212 # port down again
After:
103 # initial state after boot
103 # port change notification flood after first link change
103 # port down again
The amount of leaks are 54 each for the first two, which correspond to one leak per port when setting the initial state, then again when setting the updated state. After that its only one leak per port change notification.
KanjiMonster
commented
3 years ago
We open a new socket every time we want to set the speed of a port, but never close it. This eventually leads to hitting the maximum amount of open file descriptors, leading to various other issues.
Fix this by closing the socket on return.
Fixes: b5fe46c ("tap_manager: set port speed on tap interfaces") Signed-off-by: Jonas Gorski jonas.gorski@bisdn.de
Motivation and Context
Running out of file descriptors breaks STP, since we check sysfs for the stp state of the bridge (which then fails).
How Has This Been Tested?
watch'ls -l /proc/pidof baseboxd/fd | wc -l`` on switchBefore:
After:
The amount of leaks are 54 each for the first two, which correspond to one leak per port when setting the initial state, then again when setting the updated state. After that its only one leak per port change notification.