Change Details

Under rare circumstances, a spurious retranmission is incorrectly detected and rewound, messing up various tcpcb values, which can lead to a panic when SACK is in use. This was tracked down to happen in this section. This happens when there has been a retransmission with the previous state recorded, and on subsequent regular transmissions, TF_PREVVALID is never cleared. The alternate approach would be to reset TF_PREVVALID whenever tp->t_rxtshift is updated, such that TF_PREVVALID is only ever set, when rxtshift is also 1. This would reduce the currently necessary check for both states.

Under rare circumstances, a spurious retranmission is incorrectly detected and rewound, messing up various tcpcb values, which can lead to a panic when SACK is in use. This was tracked down to happen in this section. This happens when there has been a retransmission with the previous state recorded, and on subsequent regular transmissions, TF_PREVVALID is never cleared. In the #transport call we discussed this, and while this should be considered as a workaround, the longer term plan is to find in which codepath the PREVVALID flag is not cleared, and ultimately rely solely on this flag. Note that this will be a minuscle change in semantics of this flag, and therefore, it should also be invalideated whenever the TCP stack changes on a session. The alternate approach would be to reset TF_PREVVALID whenever tp->t_rxtshift is updated, such that TF_PREVVALID is only ever set, when rxtshift is also 1. This would reduce the currently necessary check for both states.

Under rare circumstances, a spurious retranmission is incorrectly detected and rewound, messing up various tcpcb values, which can lead to a panic when SACK is in use. This was tracked down to happen in this section. This happens when there has been a retransmission with the previous state recorded, and on subsequent regular transmissions, TF_PREVVALID is never cleared. In the #transport call we discussed this, and while this should be considered as a workaround, the longer term plan is to find in which codepath the PREVVALID flag is not cleared, and ultimately rely solely on this flag. Note that this will be a minuscle change in semantics of this flag, and therefore, it should also be invalideated whenever the TCP stack changes on a session. The alternate approach would be to reset TF_PREVVALID whenever tp->t_rxtshift is updated, such that TF_PREVVALID is only ever set, when rxtshift is also 1. This would reduce the currently necessary check for both states.