Page MenuHomeFreeBSD

tcp: Rack in a rare case we can get stuck sending a very small amount.
ClosedPublic

Authored by rrs on Dec 7 2021, 7:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Mar 23, 3:31 AM
Unknown Object (File)
Dec 27 2023, 9:47 AM
Unknown Object (File)
Dec 20 2023, 6:09 AM
Unknown Object (File)
Dec 11 2023, 11:18 PM
Unknown Object (File)
Dec 11 2023, 7:31 AM
Unknown Object (File)
Nov 11 2023, 4:29 AM
Unknown Object (File)
Nov 9 2023, 4:37 AM
Unknown Object (File)
Oct 8 2023, 12:07 PM

Details

Summary

If a tlp sending new data fails, and then the peer starts
talking to us again, we can be in a situation where the
tlp_new_data count is set, we are not in recovery and
we always send one packet every RTT. The failure
has to occur when we send the TLP initially from the ip_output()
which is rare. But if it occurs you are basically stuck.

This fixes it so we use the new_data count and clear it so
we know it will be cleared. If a failure occurs the tlp timer
will regenerate a new amount anyway so it is un-needed to
carry the value on.

Test Plan

This one is tricky to recreate since you must have a way
to have ip_output() fail on a new data tlp. This cannot
be simulated with packet drill so the only way would be
to hack in changes to make it occur.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped