Page MenuHomeFreeBSD

Address panic with PRR due to missed initialization of recover_fs

Authored by rscheff on Jan 12 2021, 11:28 AM.
Referenced Files
Unknown Object (File)
Tue, Nov 21, 2:39 PM
Unknown Object (File)
Tue, Nov 21, 2:39 PM
Unknown Object (File)
Oct 10 2023, 7:56 PM
Unknown Object (File)
Aug 27 2023, 11:13 PM
Unknown Object (File)
Aug 27 2023, 11:12 PM
Unknown Object (File)
Aug 27 2023, 11:11 PM
Unknown Object (File)
Aug 27 2023, 11:10 PM
Unknown Object (File)
Aug 26 2023, 5:18 AM



When using the base stack in conjunction with RACK, it appears that
infrequently, ++tp->t_dupacks is instantly larger than tcprexmtthresh.

This leaves the recover flightsize (sackhint.recover_fs) uninitialized,
leading to a div/0 panic.

Address this by properly initializing the variable just prior to first
use, if it is not properly initialized.

In order to prevent stale information from a prior recovery to
negatively impact the PRR calculations in this event, also clear
recover_fs once loss recovery is finished.

Finally, improve the readability of the initialization of recover_fs
when t_dupacks == tcprexmtthresh by adjusting the indentation and
using the max(1, snd_nxt - snd_una) macro.

Diff Detail

rG FreeBSD src repository
Lint Not Applicable
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Jan 12 2021, 6:52 PM
  • init recover_fs in tcp_default_fb_init() if switching stacks during fastrecovery
This revision now requires review to proceed.Jan 14 2021, 3:19 PM

Looks like the wrong diff was uploaded

This revision was not accepted when it landed; it landed in state Needs Review.Jan 20 2021, 11:22 AM
This revision was automatically updated to reflect the committed changes.

@gnn: Added initialization code for when TCP stacks get changed mid-stream, as per discussion in the @freebsd-transport call last thursday.