Re: panic: tcp_do_segment: sent too much

> On 27. Oct 2024, at 17:38, Gleb Smirnoff <glebius@FreeBSD.org> wrote:
> 
> Hi,
> 
> I just got this panic on my desktop running latest stabweek snapshot.
> 
> panic: tcp_do_segment: sent too much
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfffffe0209deb440
> kdb_backtrace() at kdb_backtrace+0x46/frame 0xfffffe0209deb4f0
> vpanic() at vpanic+0x23d/frame 0xfffffe0209deb630
> panic() at panic+0x4e/frame 0xfffffe0209deb690
> tcp_do_segment() at tcp_do_segment+0x3a6c/frame 0xfffffe0209deb8d0
> tcp_input_with_port() at tcp_input_with_port+0x15db/frame 0xfffffe0209deba60
> tcp_input() at tcp_input+0x27/frame 0xfffffe0209deba90
> ip_input() at ip_input+0x1131/frame 0xfffffe0209debb00
> netisr_dispatch_src() at netisr_dispatch_src+0x18c/frame 0xfffffe0209debb70
> netisr_dispatch() at netisr_dispatch+0x21/frame 0xfffffe0209debb90
> ether_demux() at ether_demux+0x2a5/frame 0xfffffe0209debbd0
> ether_input_internal() at ether_input_internal+0x613/frame 0xfffffe0209debc10
> ether_nh_input() at ether_nh_input+0xb1/frame 0xfffffe0209debc30
> netisr_dispatch_src() at netisr_dispatch_src+0x18c/frame 0xfffffe0209debca0
> netisr_dispatch() at netisr_dispatch+0x21/frame 0xfffffe0209debcc0
> ether_input() at ether_input+0x16c/frame 0xfffffe0209debd10
> 
> My kernel is compiled with -O0, which alleviates debugging:
Hi Gleb,

I am aware of the panic, wlosh@ reported it, and pho@ mentioned that he
can trigger it on bare metal using

cd src/tools/test/stress2/misc
./all.sh -o tcp.sh

I will try to reproduce it, once I have fix another bug reported by
pho@ related to SCTP.

Best regards
Michael
> 
> (kgdb) frame 4
> #4  0xffffffff80ea6c3c in tcp_do_segment (tp=0xfffff814a6f96000, m=0xfffff8044d546a00, th=0xfffff8044d546a82, drop_hdrlen=64, tlen=0, 
>   iptos=72 'H') at /usr/src/FreeBSD/sys/netinet/tcp_input.c:2812
> 2812                                                    KASSERT((tp->t_dupacks == 2 &&
> (kgdb) p tp->t_dupacks
> $1 = 1
> (kgdb) p tp->snd_limited
> $2 = 0 '\000'
> (kgdb) p/x tp->t_flags 
> $4 = 0x110003e4
> (kgdb) p/x tp->t_flags & 0x00000010 # TF_SENTFIN
> $5 = 0x0
> (kgdb) p tp->t_flags & 1 # TF_ACKNOW
> $15 = 0
> (kgdb) p sent
> $6 = 1507
> (kgdb) p maxseg
> $7 = 1400
> (kgdb) p oldcwnd
> $8 = 1400
> (kgdb) p oldsndmax
> $9 = 2473784830
> (kgdb) p tp->snd_max
> $10 = 2473786337
> (kgdb) p 2473786337 - 2473784830
> $11 = 1507
> (kgdb) p tp->snd_cwnd
> $12 = 2800
> (kgdb) p avail
> $13 = 2018
> (kgdb) p tp->snd_nxt - tp->snd_una
> $16 = 2018
> (kgdb) p so->so_snd.sb_acc
> $17 = 2018
> (kgdb) p *tp->snd_holes.tqh_first
> $22 = {start = 2473784319, end = 2473784358, rxmit = 2473784319, scblink = {tqe_next = 0x0, tqe_prev = 0xfffff814a6f96350}}
> 
> Apparently tcp_output() has sent more than one segment. I don't know if this old
> assertion is correct, but looks like it started to trigger.
> 
> Could this be related to 440f4ba18e3a?
> 
> -- 
> Gleb Smirnoff