|
|
|
|
|
|
by fingerlocks
69 days ago
|
|
|
Are you sure? tcp_now’s maximum cannot physically reach 2^32 because the trailing zeros of that number exceeds the bit width of data type. Therefore, tcp_now + 30000 will wrap when tcp_now is equal to 2^32 - 3000.
Your inequality sign should be strict <, otherwise the result does not follow. |
|
|
It should be that if tcp_now gets stuck before (<) (2^32 - 30000) ms from boot, it would cause deadline timers for reaping TCP_WAIT would always be greater than tcp_now because it wouldn't wrap. If stuck at or after (>=) (2^32 - 30000), it would cause them to potentially be reaped faster they should be.
Actually looking at the code a bit more, it looks like calculate_tcp_clock() is run at least once per hour even when there's no TCP traffic or sockets open, so getting into the state where it never reaps TIME_WAIT sockets which would be hard to predict if this would happen.
It also looks like if tcp_now gets stuck, other tcp timers may have problems as well.