Date: Wed, 05 Dec 2018 16:58:29 +0000 From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233414] [PowerPC64] OPTIONS DEBUG_MEMGUARD results in unbootable kernel Message-ID: <bug-233414-21-VdIDYGM1qw@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-233414-21@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233414 --- Comment #7 from Leandro Lupori <leandro.lupori@gmail.com> --- I've added the following check to cover the previous panic case, that was kmem_back_domain() being first called through zfs allocation routines and then through memguard_alloc(): At the beginning of kmem_back_domain(): if (VM_OBJECT_WOWNED(object)) locked = true; While it apparently solved the previous issue, I've hit another similar panic: root@ppcdevref:~ # panic: _mtx_lock_sleep: recursed on non-recursive mutex page pv @ /usr/src/sys/powerpc/aim/mmu_oea64.c:1383 cpuid = 70 time = 1544027411 KDB: stack backtrace: 0xe0000001d37f8a00: at .kdb_backtrace+0x5c 0xe0000001d37f8b30: at .vpanic+0x1b4 0xe0000001d37f8bf0: at .panic+0x38 0xe0000001d37f8c80: at .__mtx_lock_sleep+0x178 0xe0000001d37f8d70: at .__mtx_lock_flags+0x160 0xe0000001d37f8e20: at .moea64_enter+0x21c 0xe0000001d37f8f20: at .pmap_enter+0xb4 0xe0000001d37f8fd0: at .kmem_back_domain+0x298 0xe0000001d37f90c0: at .kmem_back_domain+0x454 0xe0000001d37f9180: at .kmem_back+0x18 0xe0000001d37f9200: at .memguard_alloc+0x188 0xe0000001d37f92f0: at .uma_zalloc_arg+0xe0 0xe0000001d37f93b0: at .uma_zalloc_pcpu_arg+0x174 0xe0000001d37f9450: at .uma_zalloc_arg+0x5a8 0xe0000001d37f9510: at .slb_free_user_cache+0xb4 0xe0000001d37f95a0: at .allocate_user_vsid+0x30c 0xe0000001d37f9650: at .va_to_vsid+0x90 0xe0000001d37f96e0: at .moea64_extract+0x254 0xe0000001d37f9770: at .moea64_enter+0x254 0xe0000001d37f9870: at .moea64_enter_object+0xa8 0xe0000001d37f9920: at .pmap_enter_object+0xa8 0xe0000001d37f99d0: at ._vm_map_unlock+0x4dc 0xe0000001d37f9aa0: at .vm_map_insert+0x550 0xe0000001d37f9ba0: at .vm_map_fixed+0x134 0xe0000001d37f9c70: at .elf64_coredump+0x1050 0xe0000001d37f9d60: at .elf64_coredump+0x1230 0xe0000001d37f9e40: at .elf64_coredump+0x162c 0xe0000001d37f9f50: at .elf64_coredump+0x2494 0xe0000001d37fa0d0: at .kern_execve+0x6fc 0xe0000001d37fa4b0: at .sys_execve+0x74 0xe0000001d37fa5b0: at .trap+0x664 0xe0000001d37fa770: at .powerpc_interrupt+0x290 0xe0000001d37fa810: user SC trap by 0x810212ec8: srr1=0x900000000000f032 r1=0x3fffffffffff8050 cr=0x44002022 xer=0x20000000 ctr=0x810212ec0 r2=0x81030ea90 KDB: enter: panic [ thread pid 87812 tid 101772 ] Stopped at .kdb_enter+0x60: ld r2, r1, 0x28 db> I didn't investigate this further, but I start to question our current approach, as we may find many more issues like this. So, I'm wondering if is there another change we could do in memguard to avoid having to work around non-recursive mutexes? Or if is there another way to catch use-after-free issues without memguard? -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233414-21-VdIDYGM1qw>