Summary: | [tcp] [panic] tcp_output() Panic String: tcp_output: len > IP_MAXPACKET on -head and stable/11 | ||
---|---|---|---|
Product: | Base System | Reporter: | Hiren Panchasara <hiren> |
Component: | kern | Assignee: | freebsd-net (Nobody) <net> |
Status: | Closed Overcome By Events | ||
Severity: | Affects Only Me | CC: | ae, glebius, kbowling, sbruno, tuexen |
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any |
Description
Hiren Panchasara
2016-10-05 18:46:04 UTC
Just hit this again on the same box. (In reply to Hiren Panchasara from comment #1) > Just hit this again on the same box. What value have len, hdrlen and ipoptlen in frame 13 or can you show `info locals` from the same frame? (In reply to Andrey V. Elsukov from comment #2) All optimized out but because it happens (or at least happened) twice, I can put some instrumentation to catch those values. I'll update when I have some more info. Just hit this on uptodate stable/11 system. r306769 | jtl | 2016-10-06 09:28:34 -0700 (Thu, 06 Oct 2016) | 8 lines Remove "long" variables from the TCP stack (not including the modular congestion control framework). may help. Updating my box and trying again if I get the same crash. Now with r306769, len is int32_t so it can actually have -ve value, I am seeing panic at /* * This KASSERT is here to catch edge cases at a well defined place. * Before, those had triggered (random) panic conditions further down. */ KASSERT(len >= 0, ("[%s:%d]: len < 0", __func__, __LINE__)); Now, putting a bit of debugs above that I figured that at following path in 'else' case the len becomes -ve if (tso) { <blah> } else { len = tp->t_maxseg - optlen - ipoptlen; sendalot = 1; } I found that tp-t_maxseg = 2, optlen = 12, ipoptlen = 0 resulting in len = -10. Clearly, t_maxseg which is supposed to be representing MSS at '2' looks wrong. I wonder if the changes in https://svnweb.freebsd.org/base?view=revision&revision=293284 somewhere caused this. Still investigating. A commit references this bug: Author: hiren Date: Tue Oct 18 02:40:25 UTC 2016 New revision: 307545 URL: https://svnweb.freebsd.org/changeset/base/307545 Log: Make sure tcp_mss() has the same check as tcp_mss_update() to have t_maxseg set to at least 64. This is still just a coverup to avoid kernel panic and not an actual fix. PR: 213232 Reviewed by: glebius MFC after: 1 week Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D8272 Changes: head/sys/netinet/tcp_input.c A commit references this bug: Author: hiren Date: Tue Nov 1 22:40:25 UTC 2016 New revision: 308184 URL: https://svnweb.freebsd.org/changeset/base/308184 Log: MFC r307545 Make sure tcp_mss() has the same check as tcp_mss_update() to have t_maxseg set to at least 64. This is still just a coverup to avoid kernel panic and not an actual fix. PR: 213232 Sponsored by: Limelight Networks Changes: _U stable/11/ stable/11/sys/netinet/tcp_input.c I think a lot has changed in the area. Please re-open, if the problem still exists. |