Page MenuHomeFreeBSD

Address panic with PRR due to missed initialization of recover_fs
ClosedPublic

Authored by rscheff on Jan 12 2021, 11:28 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Oct 29, 5:43 PM
Unknown Object (File)
Fri, Oct 18, 9:46 AM
Unknown Object (File)
Thu, Oct 17, 9:24 AM
Unknown Object (File)
Wed, Oct 16, 3:49 PM
Unknown Object (File)
Tue, Oct 15, 2:16 PM
Unknown Object (File)
Oct 15 2024, 6:13 AM
Unknown Object (File)
Oct 14 2024, 9:34 PM
Unknown Object (File)
Oct 14 2024, 1:18 PM

Details

Summary

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

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
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.