Date: Thu, 30 Aug 2018 21:11:43 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 231038] memguard is broken with options NUMA Message-ID: <bug-231038-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231038 Bug ID: 231038 Summary: memguard is broken with options NUMA Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: markj@FreeBSD.org With INVARIANTS enabled I get: # sysctl vm.memguard.desc=3Dmbuf panic: vm_reserv_extend: Domain mismatch from reservation.=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 cpuid =3D 4=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 time =3D 1535660704=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Uptime: 44s=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Dumping 1295 out of 32617 MB:..2%..12%..22%..31%..41%..51%..61%..71%..81%..= 91%=20=20 __curthread () at ./machine/pcpu.h:230=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td)=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 (kgdb) bt=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #0 __curthread () at ./machine/pcpu.h:230=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 #1 doadump (textdump=3D1) at /usr/home/markj/src/freebsd-dev/sys/kern/kern_shutdown.c:366=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #2 0xffffffff80768ab0 in kern_reboot (howto=3D260) at /usr/home/markj/src/freebsd-dev/sys/kern/kern_shutdown.c:446=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #3 0xffffffff80768f03 in vpanic (fmt=3D<optimized out>, ap=3D0xfffffe0f812= a1570) at /usr/home/markj/src/freebsd-dev/sys/kern/kern_shutdown.c:872=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 #4 0xffffffff80768c63 in panic (fmt=3D<unavailable>) at /usr/home/markj/src/freebsd-dev/sys/kern/kern_shutdown.c:799=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #5 0xffffffff80ad729c in vm_reserv_extend (req=3D546, object=3D0xffffffff8= 1312c78 <kernel_object_store>, pindex=3D2053, domain=3D0, mpred=3D<optimized out>)= =20=20=20=20=20=20=20=20=20=20 at /usr/home/markj/src/freebsd-dev/sys/vm/vm_reserv.c:879=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #6 0xffffffff80ac86fe in vm_page_alloc_domain_after (object=3D<optimized o= ut>, pindex=3D2053, domain=3D<optimized out>, req=3D546, mpred=3D0xfffff8086998d= 9e8) at /usr/home/markj/src/freebsd-dev/sys/vm/vm_page.c:1835=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #7 0xffffffff80ab5958 in kmem_back_domain (domain=3D0, object=3D<optimized= out>, addr=3D<optimized out>, size=3D4096, flags=3D<optimized out>)=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 at /usr/home/markj/src/freebsd-dev/sys/vm/vm_kern.c:440=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #8 0xffffffff80ab5c49 in kmem_back (object=3D<optimized out>, addr=3D18446741874694705152, size=3D4096, flags=3D<unavailable>) at /usr/home/markj/src/freebsd-dev/sys/vm/vm_kern.c:487=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #9 0xffffffff80aafe72 in memguard_alloc (req_size=3D256, flags=3D1) at /usr/home/markj/src/freebsd-dev/sys/vm/memguard.c:351 #10 0xffffffff80aaa4be in uma_zalloc_arg (zone=3D0xfffffe101af84000, udata=3D0xfffffe0f812a1870, flags=3D1) at /usr/home/markj/src/freebsd-dev/sys/vm/uma_core.c:2385=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #11 0xffffffff80890d58 in m_gethdr (how=3D1, type=3D255) at /usr/home/markj/src/freebsd-dev/sys/sys/mbuf.h:790=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 #12 _iflib_fl_refill (ctx=3D0xfffff8000b676800, fl=3D<optimized out>, count=3D<optimized out>) at /usr/home/markj/src/freebsd-dev/sys/net/iflib.c= :1974=20=20 #13 0xffffffff8089054b in __iflib_fl_refill_lt (ctx=3D<optimized out>, max= =3D24, fl=3D<optimized out>) at /usr/home/markj/src/freebsd-dev/sys/net/iflib.c:20= 71 #14 iflib_rxeof (rxq=3D<optimized out>, budget=3D24) at /usr/home/markj/src/freebsd-dev/sys/net/iflib.c:2723 #15 0xffffffff8088c0f9 in _task_fn_rx (context=3D0xfffff80480637580) at /usr/home/markj/src/freebsd-dev/sys/net/iflib.c:3834 #16 0xffffffff807af459 in gtaskqueue_run_locked (queue=3D0xfffff8000b1dca00= ) at /usr/home/markj/src/freebsd-dev/sys/kern/subr_gtaskqueue.c:332 #17 0xffffffff807af218 in gtaskqueue_thread_loop (arg=3D<optimized out>) at /usr/home/markj/src/freebsd-dev/sys/kern/subr_gtaskqueue.c:507 #18 0xffffffff80728e24 in fork_exit (callout=3D0xffffffff807af190 <gtaskqueue_thread_loop>, arg=3D0xfffffe101af9a068, frame=3D0xfffffe0f812a1= ac0) at /usr/home/markj/src/freebsd-dev/sys/kern/kern_fork.c:1057 #19 <signal handler called> memguard is the sole remaining consumer of the kmem_back() API, which takes= a KVA range and backs it with pages from a domain selected using an iterator.= =20 For normal allocations with kmem_malloc(), the iterator is used to select t= he vmem arena as well. The per-domain vmem arenas have a quantum equal to the superpage size, which ensures that we consistently use the same physical me= mory domain to back regions in a superpage-sized KVA range. memguard just uses a single global arena with a 4KB quantum, and basically picks a random domain which may not have the same "colour" as the 4KB KVA range. This mismatch triggers the panic. --=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-231038-227>