Date: Tue, 10 Jan 2023 06:29:28 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 268246] crash and panic using pfsync on 13.1-RELEASE Message-ID: <bug-268246-227-HgfZTpwMem@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-268246-227@https.bugs.freebsd.org/bugzilla/> References: <bug-268246-227@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=3D268246 --- Comment #16 from Kristof Provost <kp@freebsd.org> --- So my current guess is that there's something wrong with the mbuf that the pfsync code produced. Presumably that it's not as long as we're expecting i= t to be, which causes the fragmentation code to run off the end of the mbuf chain and blow up. It's not clear to me how that'd happen, but it would be useful to experiment with the pfsync interface MTU. Try setting it to less than 4k (maybe back d= own to 1500) and see if the panic goes away. m_get2() allocates external storage for > MCLBYTES (4k) allocations, but th= at should still just work, at least according to my reading of the relevant co= de. It may be that I'm missing something. The above experiment should provide a nice data point for that. --=20 You are receiving this mail because: 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-268246-227-HgfZTpwMem>