[Bug 256610] Kernel panic with ngtee

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256610

--- Comment #5 from Mark Johnston <markj@FreeBSD.org> ---
(In reply to John Baldwin from comment #4)
The full stack looks like this:

#8  <signal handler called>
#9  memmove_erms () at /usr/src/sys/amd64/amd64/support.S:547
#10 0xffffffff80c80f18 in m_dup (m=0xfffff8021e841200, 
    m@entry=0xfffff801345d9d00, how=how@entry=1)
    at /usr/src/sys/kern/uipc_mbuf.c:722
#11 0xffffffff834ab3c1 in ng_ipfw_input (m0=<optimized out>, 
    fwa=0xfffffe0144090300, tee=false) at /usr/src/sys/netgraph/ng_ipfw.c:324
#12 0xffffffff82936df0 in ipfw_check_packet (m0=0xfffffe01440904e8, 
    ifp=0xfffff80004e5b800, flags=131072, ruleset=<optimized out>, 
    inp=0xfffff8004cff35b8) at /usr/src/sys/netpfil/ipfw/ip_fw_pfil.c:297
#13 0xffffffff80d2a8c7 in pfil_run_hooks (head=<optimized out>, p=..., 
    ifp=ifp@entry=0xfffff80004e5b800, flags=flags@entry=131072, 
    inp=inp@entry=0xfffff8004cff35b8) at /usr/src/sys/net/pfil.c:187
#14 0xffffffff80d9f287 in ip_output_pfil (mp=0xfffffe01440904e8, 
    ifp=0xfffff80004e5b800, flags=0, inp=0xfffff8004cff35b8, 
    dst=0xfffff8004cff3760, fibnum=<optimized out>, error=<optimized out>)
    at /usr/src/sys/netinet/ip_output.c:130
#15 ip_output (m=m@entry=0xfffff801345d9d00, opt=<optimized out>, 
    ro=<optimized out>, flags=<optimized out>, imo=imo@entry=0x0, 
    inp=<optimized out>) at /usr/src/sys/netinet/ip_output.c:705
#16 0xffffffff80db8cab in tcp_output (tp=<optimized out>)
    at /usr/src/sys/netinet/tcp_output.c:1544
#17 0xffffffff80dccfff in tcp_usr_ready (so=<optimized out>, 
    m=0xfffff802e78b3d00, count=<optimized out>)
    at /usr/src/sys/netinet/tcp_usrreq.c:1303
#18 0xffffffff80bef395 in sendfile_iodone (arg=arg@entry=0xfffff8035b9cdb00, 
    pa=<optimized out>, pa@entry=0x0, count=<optimized out>, count@entry=0, 
    error=<optimized out>) at /usr/src/sys/kern/kern_sendfile.c:399
#19 0xffffffff80beebc9 in vn_sendfile (fp=<optimized out>, sockfd=34, 
    hdr_uio=0x0, trl_uio=0x0, offset=<optimized out>, nbytes=<optimized out>, 
    sent=0xfffffe0144090a88, flags=0, td=0xfffffe0145810ac0)
    at /usr/src/sys/kern/kern_sendfile.c:1194
#20 0xffffffff80bef7c7 in fo_sendfile (fp=0xfffff8002b911034, sockfd=0, 
    hdr_uio=0x7cc, trl_uio=0x7cc, offset=-8795362095052, 
    nbytes=722828843999576199, sent=0xfffffe0144090a88, flags=730927156, 
    td=0xfffffe0145810ac0) at /usr/src/sys/sys/file.h:411
#21 sendfile (td=0xfffffe0145810ac0, uap=0xfffffe0145810ea8, 
    compat=<optimized out>) at /usr/src/sys/kern/kern_sendfile.c:1324
#22 0xffffffff81083ede in syscallenter (td=<optimized out>)
    at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189

> While we could patch m_dup(), I don't know we want to enforce the policy that the dup is always unmapped?

Did you mean mapped?  In any case, yeah, I was wondering if it's really a good
idea to return a mapped chain.  But if a consumer is m_dup()ing something then
it probably intends to write to the dup anyway.  m_copypacket() should be used
otherwise.

-- 
You are receiving this mail because:
You are the assignee for the bug.