SOL: Another attempt to fix coredump issue
The commit "SOL: Fix coredump due to recursive call deadlock"
(5499bf862d1240bdbc061afc6e3d4f332c31329a) tried to fix coredump
issue when the buffer size is larger than the send threshold (i.e. user
types too fast in the SoL session). Despite of the commit message the
provided solution doesn't seem to fix the crashdump issue.
Revert 5499bf862d and implement a proper solution.
Normally 'enableAccumulateTimer()' launches a timer to accumulate data
before send, and after the timeout the 'charAccTimerHandler()' sends
all the data via the 'sendOutboundPayload()' function.
If the buffer is not ready at that moment, the 'charAccTimerHandler()'
relaunches the timer via the 'enableAccumulateTimer()' call.
At the same time the 'enableAccumulateTimer()' function has an
optimization: if the data size is more than 'sendThreshold' there is no
point in timer, data can be send directly from the function. For that
the current code calls the 'charAccTimerHandler()'.
In the end this can create an endless recursion in times when buffer is
not ready:
enableAccumulateTimer()
charAccTimerHandler()
sendOutboundPayload()
enableAccumulateTimer()
...
To solve the issue we need to be careful about when we call the
'enableAccumulateTimer()' function:
- first of all we don't need to call it from 'sendOutboundPayload()'
since it is already called from the 'charAccTimerHandler()',
- secondary in the 'enableAccumulateTimer' optimization case we don't
need to call 'charAccTimerHandler()' which can re-launch timer but can
just use 'sendOutboundPayload()' directly.
Tested:
SOL console in ipmitool works fine if holding arrow up/down key
for a long time.
Change-Id: Ibec03fc1394f23ba39b6f2d5a929928588e00590
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
1 file changed