Date: Mon, 21 Jun 2021 16:01:40 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 256610] Kernel panic with ngtee Message-ID: <bug-256610-7501-GGLoNuFBPN@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256610-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-256610-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=3D256610 --- Comment #4 from John Baldwin <jhb@FreeBSD.org> --- I'm curious how this is using unmapped mbufs? Does ngtee use sendfile(2) u= nder the hood? While we could patch m_dup(), I don't know we want to enforce the policy that the dup is always unmapped? That said, I think fixing m_dup is probably a single line change to replace the 'bcopy' with 'm_copydata' as is done in m_defrag(): diff --git a/sys/kern/uipc_mbuf.c b/sys/kern/uipc_mbuf.c index b9e716b411be..1a2098c7c536 100644 --- a/sys/kern/uipc_mbuf.c +++ b/sys/kern/uipc_mbuf.c @@ -719,7 +719,7 @@ m_dup(const struct mbuf *m, int how) while (n->m_len < nsize && m !=3D NULL) { int chunk =3D min(nsize - n->m_len, m->m_len - moff= ); - bcopy(m->m_data + moff, n->m_data + n->m_len, chunk= ); + m_copydata(m, moff, chunk, n->m_data + n->m_len); moff +=3D chunk; n->m_len +=3D chunk; remain -=3D chunk; --=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-256610-7501-GGLoNuFBPN>