aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/mca/Kconfig
diff options
context:
space:
mode:
authorIlpo Järvinen <ilpo.jarvinen@helsinki.fi>2007-11-14 15:55:09 -0800
committerDavid S. Miller <davem@davemloft.net>2007-11-14 15:55:09 -0800
commite1cd8f78f8cbfa314a095dbf704707217c8ee197 (patch)
tree3fd93e961b6e0d45813a03bf1c2087f8628ca7b1 /drivers/mca/Kconfig
parentc67625a1ecd7caf4c0490fc5278d6bb736a5297f (diff)
downloadkernel_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