The messages you had in the other mail are very likely symptom of the
same problem, it's just hard to tell from them where it really originates
from (because it would requires expensive verification that nobody wants
to do by default after simple operations). In many cases that WARN_ON is
simply too late to tell when the problem causing adjustment/corruption
WARNING: at net/ipv4/tcp_output.c:1807 tcp_simple_retransmit()
[<c0104cb3>] show_trace_log_lvl+0x1a/0x2f
[<c0105563>] show_trace+0x12/0x14
[<c0105668>] dump_stack+0x15/0x17
[<c02f6a79>] tcp_simple_retransmit+0xfa/0x185
[<c02fa072>] tcp_v4_err+0x35d/0x4cb
[<c0301f7d>] icmp_unreach+0x327/0x352
Hmm, that's related to path MTU things... It might have something to do
Yeah, it's more likely a miscount somewhere rather than corruption but
that wasn't obvious from the first mail...
...but alas, I haven't yet been able to come up with any theory on how
Yeah, they are expected, the write_queue is empty. Another cause for
those could have been corrupted write_queue (that's why I asked for the
Underflows by one. ...We should just find out what causes this and fix
Thanks about them, though they're not that useful because the problem
No, it won't happen like that. ...I'd say that gdb is just confused. In
case packets_out is zero (it occurs after a cumulative ACK only), for sure
skb will become NULL because the retransmit_skb_hint was cleared due to
cumulative ACK.
The crash location is the expected one in case packets_out gets zero
during recovery and lost_out is miscounted/corrupt, as your dump shows.
Anyway, thanks for digging these out.
Here's a bruteforce patch below... Since you had couple of them during
your overnight test, I'm sure it's relatively easy to catch... The
first place where the tcp_verify_lost is triggered is the most
interesting, rest are likely ripples due to that earlier corruption...
(Hopefully I've placed them this time to places where both queue and ...
