Date: Fri, 16 Jun 2023 18:59:29 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 271991] Crash on some network packets with fresh stable Message-ID: <bug-271991-227-OGbq1HZMXX@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271991-227@https.bugs.freebsd.org/bugzilla/> References: <bug-271991-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=3D271991 --- Comment #5 from Mark Johnston <markj@FreeBSD.org> --- (In reply to Ivan Rozhuk from comment #3) I don't think m_pullup() is the right layer to handle unmapped mbufs. It g= ets called very frequently, and mb_unmapped_to_ext() is expensive even when it = does nothing, since it has to visit each mbuf in the chain. (In reply to Ivan Rozhuk from comment #4) The patch to m_pullup() assumes that "m" is mapped, which might not be the case. Hmm, virtio-net does not set IFCAP_MEXTPG, so the protocol layer will map mbufs. This is actually rather suboptimal, and the virtio driver should le= arn to handle unmapped mbufs. e1000 should handle unmapped mbufs though. Do y= ou see "NOMAP" in the interface flags as reported by ifconfig? (In reply to Ivan Rozhuk from comment #0) It would be useful to see output from 'p/x *n' in frame 9. I think it wouldn't be too difficult to make bpf_filter() work with unmapped mbufs. m_xword() and m_xhalf() would need a bit of special logic. And I t= hink ng_bpf() doesn't need to do this pullup at all unless BPF JIT is enabled, a= nd that's not even compiled into GENERIC. --=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-271991-227-OGbq1HZMXX>