panic after LOR, 2nd netmap_mem2.c, 1st vm_fault.c

[Vincenzo Maffione]

Hi,
  I see this happening all the time, it's a locking problem.
It does not cause a panic, usually.
Can you please open an issue on the github tracker (
https://github.com/luigirizzo/netmap)?

Thanks,
  Vincenzo

2017-06-07 18:28 GMT+02:00 Harry Schmalzbauer <freebsd at omnilan.de>:

>  Bezüglich Harry Schmalzbauer's Nachricht vom 07.06.2017 16:20 (localtime):
> >  lock order reversal: (sleepable after non-sleepable)
> >  1st 0xfffff8007519a960 vm object (vm object) @
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/vm/vm_fault.c:572
> >  2nd 0xfffff8003299b000 (d)->nm_mtx ((d)->nm_mtx) @
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_mem2.c:577
> > stack backtrace:
> > #0 0xffffffff805e7900 at witness_debugger+0x70
> > #1 0xffffffff805e77f3 at witness_checkorder+0xe23
> > #2 0xffffffff80591f4e at _sx_xlock+0x5e
> > #3 0xffffffff8042275a at netmap_mem2_ofstophys+0x2a
> > #4 0xffffffff8041f3ab at netmap_dev_pager_fault+0x3b
> > #5 0xffffffff8082d834 at dev_pager_getpages+0x74
> > #6 0xffffffff80856d2a at vm_pager_get_pages+0x4a
> > #7 0xffffffff8083aa92 at vm_fault_hold+0xa52
> > #8 0xffffffff80839ff5 at vm_fault+0x75
> > #9 0xffffffff8088048f at trap_pfault+0xff
> > #10 0xffffffff8087fc38 at trap+0x348
> > #11 0xffffffff808645d1 at calltrap+0x8
> >
> > KDB: stack backtrace:
> > #0 0xffffffff805ca4b7 at kdb_backtrace+0x67
> > #1 0xffffffff8058a3f6 at vpanic+0x186
> > #2 0xffffffff8058a473 at panic+0x43
> > #3 0xffffffff8056b564 at __mtx_assert+0xb4
> > #4 0xffffffff80544780 at knlist_add+0x20
> > #5 0xffffffff8041ead0 at netmap_kqfilter+0x110
> > #6 0xffffffff804657f7 at devfs_kqfilter_f+0x77
> > #7 0xffffffff80542a0b at kqueue_register+0x78b
> > #8 0xffffffff80543432 at kqueue_kevent+0x92
> > #9 0xffffffff80543336 at kern_kevent_fp+0x96
> > #10 0xffffffff8054324f at kern_kevent+0x9f
> > #11 0xffffffff80543058 at sys_kevent+0x138
> > #12 0xffffffff80880dda at amd64_syscall+0x57a
> > #13 0xffffffff808648bb at Xfast_syscall+0xfb
> >
> > #0  doadump (textdump=<value optimized out>) at pcpu.h:222
> > #1  0xffffffff80589e70 in kern_reboot (howto=260) at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:366
> > #2  0xffffffff8058a430 in vpanic (fmt=<value optimized out>, ap=<value
> > optimized out>)
> >     at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:759
> > #3  0xffffffff8058a473 in panic (fmt=<value optimized out>) at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690
> > #4  0xffffffff8056b564 in __mtx_assert (c=0x0, what=0, file=0x0, line=0)
> > at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_
> mutex.c:1000
> > #5  0xffffffff80544780 in knlist_add (knl=0xfffffe000a055450,
> > kn=0xfffff8026d097e80, islocked=1)
> >     at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:2089
> > #6  0xffffffff8041ead0 in netmap_kqfilter (dev=<value optimized out>,
> > kn=0xfffff8026d097e80)
> >     at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/
> netmap_freebsd.c:1354
> > #7  0xffffffff804657f7 in devfs_kqfilter_f (fp=0xfffff8001faf8780,
> > kn=0xfffff8026d097e80)
> >     at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/devfs/
> devfs_vnops.c:837
> > #8  0xffffffff80542a0b in kqueue_register (kq=0xfffff8001a65c000,
> > kev=0xfffffe045b4dc650, td=0xfffff8014ca71000, waitok=<value optimized
> out>)
> >     at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1334
> > #9  0xffffffff80543432 in kqueue_kevent (kq=0xfffff8001a65c000,
> > td=0xfffff8014ca71000, nchanges=4, nevents=<value optimized out>,
> > k_ops=0xfffffe045b4dc8a0,
> >     timeout=<value optimized out>) at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1019
> > #10 0xffffffff80543336 in kern_kevent_fp (td=0xfffff8014ca71000,
> > fp=<value optimized out>, nchanges=4, nevents=<value optimized out>,
> >     k_ops=<value optimized out>, timeout=<value optimized out>) at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1050
> > #11 0xffffffff8054324f in kern_kevent (td=0xfffff8014ca71000, fd=7,
> > nchanges=4, nevents=0, k_ops=0xfffffe045b4dc8a0, timeout=0x0)
> >     at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_
> event.c:993
> > #12 0xffffffff80543058 in sys_kevent (td=0xfffff8014ca71000,
> > uap=0xfffffe045b4dca30) at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:925
> > #13 0xffffffff80880dda in amd64_syscall (td=0xfffff8014ca71000,
> > traced=0) at subr_syscall.c:135
> > #14 0xffffffff808648bb in Xfast_syscall () at
> > /usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/
> exception.S:396
> > #15 0x000000080122813a in ?? ()
> …
> > Does anybody have a quick idea if it's easily fixable, or a complicated
> > issue, possibly caused due to MFC boch?
>
> Similar panic happens with stable/11 native netmap code, see
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219846
>
> Hope this can be fixed before 11.1-RELEASE?
>
> Thanks,
>
> -harry
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>



-- 
Vincenzo Maffione