VIMAGE + PF crash in mbuf destructor

[Nikos Vassiliadis]

On 07/22/13 09:32, Craig Rodrigues wrote:
> Hi,
>
> I used a kernel config with the following lines:
>
> include GENERIC
> options VIMAGE
>
> and compiled a CURRENT kernel from svn://svn.freebsd.org/base/head@253346 .
>
> I also have PF enabled on my system.
>
> Once in a while I have been getting kernel panics like these:
>
>
> ====================================================================
> (kgdb) #0  doadump (textdump=1) at pcpu.h:236
> #1  0xffffffff808bc617 in kern_reboot (howto=260)
>      at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:447
> #2  0xffffffff808bcb25 in vpanic (fmt=<value optimized out>,
>      ap=<value optimized out>)
>      at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:754
> #3  0xffffffff808bcb73 in panic (fmt=<value optimized out>)
>      at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:683
> #4  0xffffffff8033dff7 in db_panic (addr=<value optimized out>,
>      have_addr=<value optimized out>, count=<value optimized out>,
>      modif=<value optimized out>)
>      at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:482
> #5  0xffffffff8033dbcd in db_command (cmd_table=<value optimized out>)
>      at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:449
> #6  0xffffffff8033d944 in db_command_loop ()
>      at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:502
> #7  0xffffffff803402f0 in db_trap (type=<value optimized out>, code=0)
>      at /usr/home/rodrigc/freebsd/head/sys/ddb/db_main.c:231
> #8  0xffffffff808f3623 in kdb_trap (type=12, code=0, tf=<value optimized
> out>)
>      at /usr/home/rodrigc/freebsd/head/sys/kern/subr_kdb.c:654
> #9  0xffffffff80cda43a in trap_fatal (frame=0xffffff811dbab6b0,
>      eva=<value optimized out>)
>      at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:868
> #10 0xffffffff80cda6f4 in trap_pfault (frame=0x0, usermode=0)
>      at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:699
> #11 0xffffffff80cd9ef0 in trap (frame=0xffffff811dbab6b0)
>      at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:463
> #12 0xffffffff80cc31a2 in calltrap ()
>      at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/exception.S:232
> #13 0xffffffff8208f7b7 in pf_mtag_free (t=0xfffffe00a8797870)
>      at
> /usr/home/rodrigc/freebsd/head/sys/modules/pf/../../netpfil/pf/pf.c:830
> #14 0xffffffff808a51c9 in mb_dtor_mbuf (mem=0xfffffe000d0bc500, size=256,
>      arg=0x0) at /usr/home/rodrigc/freebsd/head/sys/kern/kern_mbuf.c:499
> #15 0xffffffff80b55d4d in uma_zfree_arg (zone=0xfffffe000b4ab900,
>      item=0xfffffe000d0bc500, udata=0x0)
>      at /usr/home/rodrigc/freebsd/head/sys/vm/uma_core.c:2560
> #16 0xffffffff8092d1f5 in m_freem (mb=<value optimized out>) at uma.h:364
> #17 0xffffffff8058ba72 in iwn_tx_done (sc=0xffffff8000974000,
>      desc=<value optimized out>, ackfailcnt=16, status=131 '\203')
>      at /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:2817
> #18 0xffffffff80583e60 in iwn_notif_intr (sc=0xffffff8000974000)
>      at /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:3015
> #19 0xffffffff80583684 in iwn_intr (arg=0xffffff8000974000)
>      at /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:3306
> #20 0xffffffff8088daf3 in intr_event_execute_handlers (
>      p=<value optimized out>, ie=0xfffffe000b696600)
>      at /usr/home/rodrigc/freebsd/head/sys/kern/kern_intr.c:1263
> #21 0xffffffff8088e4c6 in ithread_loop (arg=0xfffffe000b31b040)
>      at /usr/home/rodrigc/freebsd/head/sys/kern/kern_intr.c:1276
> #22 0xffffffff8088b3f4 in fork_exit (
>      callout=0xffffffff8088e420 <ithread_loop>, arg=0xfffffe000b31b040,
>      frame=0xffffff811dbabac0)
>      at /usr/home/rodrigc/freebsd/head/sys/kern/kern_fork.c:991
> #23 0xffffffff80cc36de in fork_trampoline ()
>      at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/exception.S:606
> #24 0x0000000000000000 in ?? ()
> Current language:  auto; currently minimal
> (kgdb)
> ====================================================================
>
>
> It turns out that in this file: src/sys/netpfil/pf/pf.c
>
>      826 static void
>      827 pf_mtag_free(struct m_tag *t)
>      828 {
>      829
>      830         uma_zfree(V_pf_mtag_z, t);
>      831 }
>
> when line 830 is hit, it turns out that curthread->td_vnet is NULL.
>
> Does anyone have an idea as to the best place
> to put CURVNET_SET() to avoid this problem?
>
> I am a little less famiiar with mbuf and pf.

Hi,

I think this comes from the eventhandlers pf installs to handle
ifnet events. It seems like a wifi event causes this code to run
and the context is not set. Does the panic happen only when you
use vnet jails?

Could you try putting all evenhandlers in an
'if (IS_DEFAULT_VNET(curvnet))' block?

It's here:
http://fxr.watson.org/fxr/source/netpfil/pf/pf_if.c#L127
the pfi_*_cookie = ... lines.

I am not sure if this would be enough though since it might
panic in other places.

HTH, Nikos