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
F174542342: D28114.id82148.diff
Sun, Oct 4, 1:26 AM
F174454559: D28114.id82148.diff
Sat, Oct 3, 8:58 AM
Unknown Object (File)
Wed, Sep 30, 4:16 PM
Unknown Object (File)
Mon, Sep 28, 12:04 AM
Unknown Object (File)
Sun, Sep 20, 10:15 AM
Unknown Object (File)
Sat, Sep 19, 3:50 PM
Unknown Object (File)
Fri, Sep 18, 8:36 AM
Unknown Object (File)
Sat, Sep 12, 10:15 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
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.