Date: Fri, 24 Jun 2022 14:35:21 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 264257] [tcp] Panic: Fatal trap 12: page fault while in kernel mode (if_io_tqg_4) - m_copydata ... at /usr/src/sys/kern/uipc_mbuf.c:659 Message-ID: <bug-264257-7501-RYLYWSxQ82@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-264257-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-264257-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264257 --- Comment #74 from Richard Scheffenegger <rscheff@freebsd.org> --- The offending TCP sessions we've seen so far all seem to be regular https sessions. For (yet unknown) reasons, rarely the FIN bit seems to get accoun= ted more than once - up to 6 times, from one of the logging patched kernels. With SACK rescue retransmissions, that can lead to having the sequence numb= er of one or more FIN bits included in the block which is to be retransmitted - and the panic happens, when the data byte at the sequence number of the FIN= bit is tried to be retranmitted... In your case, even though you didn't have SACK rescue retransmissions enabl= ed, the client of the offending session appears to have SACK'ed the 2nd retransmission of the (and empty) FIN packet with a "too high" sequence num= ber, in effect resulting in the same issue. This should be happening much less frequently than with the SACK rescue retransmissions. At the same time, it appears, that double-counting of FIN bits happens quite frequently, but is not easy to reproduce. Thus we are currently working on a patch which exposes this (in INVARIANTS kernels with panics, in production kernels by logging that unexpected state, and clearing it "on the fly"). See D35446 --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264257-7501-RYLYWSxQ82>