[Bug 233414] [PowerPC64] OPTIONS DEBUG_MEMGUARD results in unbootable kernel

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233414

--- Comment #7 from Leandro Lupori <leandro.lupori at 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 at 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.