[Bug 282605] panic: tcp_do_segment: sent too much

2024-11-24 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605

Mark Linimon  changed:

   What|Removed |Added

   Assignee|transport@FreeBSD.org   |rsch...@freebsd.org
  Flags||mfc-stable14?,
   ||mfc-stable13?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 282605] panic: tcp_do_segment: sent too much

2024-11-14 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605

--- Comment #6 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=8f5a2e216f4cb955150c8f88ab21eaecc5adc8b9

commit 8f5a2e216f4cb955150c8f88ab21eaecc5adc8b9
Author: Richard Scheffenegger 
AuthorDate: 2024-11-14 08:19:34 +
Commit: Richard Scheffenegger 
CommitDate: 2024-11-14 08:19:49 +

tcp: fix cwnd recalculation during limited transmit

Properly calculate the expected flight size (cwnd) during
limited transmit. Exclude the SACK scoreboard from
consideration when still in limited transmit.

PR: 282605
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D47541

 sys/netinet/tcp_input.c  | 2 +-
 sys/netinet/tcp_output.c | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 282605] panic: tcp_do_segment: sent too much

2024-11-11 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605

Alexander Leidinger  changed:

   What|Removed |Added

 CC||netch...@freebsd.org

--- Comment #5 from Alexander Leidinger  ---
I just run into this panic, on the ipv6 side I would guess (current as of
2024-10-30-120714):
---snip---
[365136] panic: tcp_do_segment: sent too much
[365136] cpuid = 1
[365136] time = 1731354815
[365136] KDB: stack backtrace:
[365136] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe04314f7790
[365136] vpanic() at vpanic+0x136/frame 0xfe04314f78c0
[365136] panic() at panic+0x43/frame 0xfe04314f7920
[365136] tcp_do_segment() at tcp_do_segment+0x2852/frame 0xfe04314f79f0
[365136] tcp_input_with_port() at tcp_input_with_port+0x10e2/frame
0xfe04314f7b40
[365136] tcp6_input_with_port() at tcp6_input_with_port+0x6a/frame
0xfe04314f7b70
[365136] tcp6_input() at tcp6_input+0xb/frame 0xfe04314f7b80
[365136] ip6_input() at ip6_input+0xc76/frame 0xfe04314f7c60
[365136] netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame
0xfe04314f7cc0
[365136] ether_demux() at ether_demux+0x16a/frame 0xfe04314f7cf0
[365136] ether_nh_input() at ether_nh_input+0x3cf/frame 0xfe04314f7d40
[365136] netisr_dispatch_src() at netisr_dispatch_src+0xb9/frame
0xfe04314f7da0
[365136] ether_input() at ether_input+0xd5/frame 0xfe04314f7e00
[365136] epair_tx_start_deferred() at epair_tx_start_deferred+0xd4/frame
0xfe04314f7e40
[365136] taskqueue_run_locked() at taskqueue_run_locked+0x1c7/frame
0xfe04314f7ec0
[365136] taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame
0xfe04314f7ef0
[365136] fork_exit() at fork_exit+0x87/frame 0xfe04314f7f30
[365136] fork_trampoline() at fork_trampoline+0xe/frame 0xfe04314f7f30
[365136] --- trap 0x3de64570, rip = 0, rsp = 0, rbp = 0 ---
[365136] Uptime: 4d5h25m36s
[365136] Dumping 50824 out of 73621
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
---snip--

Parts of the crashdump output (full output available on request):
---snip---
#5  0x806b6b72 in tcp_do_segment (tp=0xf80da7abfa80,
m=, th=0xf804c5190a96, drop_hdrlen=72, tlen=0,
iptos=)
at /space/system/usr_src/sys/netinet/tcp_input.c:1548
to = {to_flags = 128, to_tsval = 4294965249, to_tsecr = 4546,
  to_sacks = 0xf804c5190aae
"\aa\217\345\aa\225}\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255",
,
  to_signature = 0x4 ,
  to_tfo_cookie = 0xfe04314f79c0 "\340yO1", to_mss = 22215,
  to_wscale = 111 'o', to_nsacks = 1 '\001', to_tfo_len = 255 '\377',
  to_spare = 2154633376}
maxseg = 1432
inp = 0xf80da7abfa80
needoutput = 0
incforsyn = 
so = 0xf8051a0ffc00
inc = 
thflags = 
sack_changed = 
nsegs = 1
s = 
tiwin = 
rstreason = 
todrop = 
acked = 
tfo_syn = 
mfree = 
ourfinisacked = 
win = 
close = 
#6  0x806b3602 in tcp_input_with_port (mp=mp@entry=0xfe04314f7bc8,
offp=offp@entry=0xfe04314f7bc0, proto=, port=0)
at /space/system/usr_src/sys/netinet/tcp_input.c:1158
so = 0xf8051a0ffc00
to = {to_flags = 0, to_tsval = 0, to_tsecr = 719386432,
  to_sacks = 0xf80727e1a038 "\001",
  to_signature = 0xf80727e1a084 "",
  to_tfo_cookie = 0x5bbafa8e0073 , to_mss = 37456, to_wscale = 5 '\005',
  to_nsacks = 0 '\000', to_tfo_len = 0 '\000', to_spare = 590855}
m = 0xf804c5190a00
th = 0xf804c5190a96
ip = 0x0
inp = 
tp = 
optp = 0xf804c5190aaa
"\001\001\005\n\aa\217\345\aa\225}\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255\336\336\300\255",

optlen = 12
tlen = 
rstreason = 
fwd_tag = 0x0
ip6 = 0xf804c5190a6e
s = 0x0
off0 = 
iptos = 0 '\000'
off = 
len = 
ipttl = 
thflags = 
drop_hdrlen = 72
lookupflag = 
isipv6 = 
#7  0x806b247a in tcp6_input_with_port (mp=0xfe04314f7bc8,
offp=0xfe04314f7bc0, proto=, port=port@entry=0)
at /space/system/usr_src/sys/netinet/tcp_input.c:594
m = 0xf804c5190a00
ip6 = 
ia6 = 
#8  0x806b3d5b

[Bug 282605] panic: tcp_do_segment: sent too much

2024-11-08 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605

Richard Scheffenegger  changed:

   What|Removed |Added

 Status|Open|In Progress

--- Comment #4 from Richard Scheffenegger  ---
Agree, D47474 masks the problem, which appears to be an interaction between the
new tcp transmission selection code, and the combination of RTO followed by a
SACK loss recovery in close succession.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 282605] panic: tcp_do_segment: sent too much

2024-11-07 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605

--- Comment #3 from Michael Tuexen  ---
(In reply to Mark Johnston from comment #1)
It is not yet fixed. I attached a packetdrill reproducer. I am right now
testing review D47474 which seems to avoid triggering the relevant KASSERT so
far. The reproducer also does not trigger the KASSERT anymore with review
D47474. But it is not fully understood, what is going on.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 282605] panic: tcp_do_segment: sent too much

2024-11-07 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605

--- Comment #2 from Michael Tuexen  ---
Created attachment 255012
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255012&action=edit
packetdrill reproducer

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 282605] panic: tcp_do_segment: sent too much

2024-11-07 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605

Mark Johnston  changed:

   What|Removed |Added

 Status|New |Open
 CC||gleb...@freebsd.org,
   ||ma...@freebsd.org,
   ||rsch...@freebsd.org,
   ||tue...@freebsd.org
   Assignee|b...@freebsd.org|transport@FreeBSD.org

--- Comment #1 from Mark Johnston  ---
There have been a couple of TCP commits since your revision - is it possible
that this is already fixed?

-- 
You are receiving this mail because:
You are the assignee for the bug.