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/> References: <bug-233414-21@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233414 --- 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 t= hen through memguard_alloc(): At the beginning of kmem_back_domain(): if (VM_OBJECT_WOWNED(object)) locked =3D true; While it apparently solved the previous issue, I've hit another similar pan= ic: root@ppcdevref:~ # panic: _mtx_lock_sleep: recursed on non-recursive mutex = page pv @ /usr/src/sys/powerpc/aim/mmu_oea64.c:1383 cpuid =3D 70 time =3D 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=3D0x900000000000f032 r1=3D0x3fffffffffff8050 cr=3D0x44002022 xer=3D0x20000000 ctr=3D= 0x810212ec0 r2=3D0x81030ea90 KDB: enter: panic [ thread pid 87812 tid 101772 ] Stopped at .kdb_enter+0x60: ld r2, r1, 0x28 db>=20 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 avo= id having to work around non-recursive mutexes? Or if is there another way to catch use-after-free issues without memguard? --=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-233414-21-VdIDYGM1qw>