From owner-freebsd-ppc@freebsd.org Wed Dec 5 16:58:31 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62184131BB3B for ; Wed, 5 Dec 2018 16:58:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EDB007D75E for ; Wed, 5 Dec 2018 16:58:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B0DBA131BB39; Wed, 5 Dec 2018 16:58:30 +0000 (UTC) Delivered-To: ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DC27131BB38 for ; Wed, 5 Dec 2018 16:58:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10CE27D757 for ; Wed, 5 Dec 2018 16:58:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2A494F5E3 for ; Wed, 5 Dec 2018 16:58:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id wB5GwTbr052844 for ; Wed, 5 Dec 2018 16:58:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id wB5GwTTX052843 for ppc@FreeBSD.org; Wed, 5 Dec 2018 16:58:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233414] [PowerPC64] OPTIONS DEBUG_MEMGUARD results in unbootable kernel Date: Wed, 05 Dec 2018 16:58:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: leandro.lupori@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: EDB007D75E X-Spamd-Result: default: False [-0.54 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.53)[-0.533,0]; NEURAL_SPAM_LONG(0.03)[0.034,0]; ASN(0.00)[asn:10310, ipnet:2001:1900:2254::/48, country:US]; NEURAL_HAM_SHORT(-0.04)[-0.044,0] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 16:58:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233414 --- Comment #7 from Leandro Lupori --- 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.=