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)
Feb 27 2024, 1:06 AM
Unknown Object (File)
Jan 27 2024, 7:48 AM
Unknown Object (File)
Jan 27 2024, 7:48 AM
Unknown Object (File)
Jan 27 2024, 7:47 AM
Unknown Object (File)
Jan 27 2024, 7:46 AM
Unknown Object (File)
Jan 27 2024, 7:46 AM
Unknown Object (File)
Jan 26 2024, 4:47 PM
Unknown Object (File)
Dec 20 2023, 6:13 AM

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
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 36197
Build 33086: arc lint + arc unit

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.