diff options
| author | Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> | 2007-11-14 15:55:09 -0800 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2007-11-14 15:55:09 -0800 |
| commit | e1cd8f78f8cbfa314a095dbf704707217c8ee197 (patch) | |
| tree | 3fd93e961b6e0d45813a03bf1c2087f8628ca7b1 /drivers/mca/Kconfig | |
| parent | c67625a1ecd7caf4c0490fc5278d6bb736a5297f (diff) | |
| download | kernel_samsung_smdk4412-e1cd8f78f8cbfa314a095dbf704707217c8ee197.zip kernel_samsung_smdk4412-e1cd8f78f8cbfa314a095dbf704707217c8ee197.tar.gz kernel_samsung_smdk4412-e1cd8f78f8cbfa314a095dbf704707217c8ee197.tar.bz2 | |
[TCP] FRTO: Clear frto_highmark only after process_frto that uses it
I broke this in commit 3de96471bd7fb76406e975ef6387abe3a0698149:
[TCP]: Wrap-safed reordering detection FRTO check
tcp_process_frto should always see a valid frto_highmark. An invalid
frto_highmark (zero) is very likely what ultimately caused a seqno
compare in tcp_frto_enter_loss to do the wrong leading to the LOST-bit
leak.
Having LOST-bits integry ensured like done after commit
23aeeec365dcf8bc87fae44c533e50d0bb4f23cc:
[TCP] FRTO: Plug potential LOST-bit leak
won't hurt. It may still be useful in some other, possibly legimate,
scenario.
Reported by Chazarain Guillaume <guichaz@yahoo.fr>.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/mca/Kconfig')
0 files changed, 0 insertions, 0 deletions