From owner-svn-src-head@freebsd.org Fri Jun 12 02:25:36 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC62032A1E1; Fri, 12 Jun 2020 02:25:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49jl280mR7z3Vw6; Fri, 12 Jun 2020 02:25:35 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-io1-xd43.google.com with SMTP id r2so8713343ioo.4; Thu, 11 Jun 2020 19:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=NqRsFyli/EmHyKWWTtEHVl2EkHZ2InLe+Tuh08JVv20=; b=UAc04+/a/WE0qz8CjqspFyeoyonPvtB6JscXKU8xg1S6dGaeL2/gIZgu3AB2kiK4t2 k3G1JgOJK8rOtC+tNtoiBXRmjQ780PBGt1gYqxuyIJVbZ1mwiqXX7xmL7ogHvvzpgp+d ndgTm3kBlDCtHswtcWIiQ8/wf70q2KU9gq5+hMnDPad/Ogf1H6NZ6AG/NBxI4G56GaS6 EBJxrV9Jgx0ippbu8AKeHYRS2bSgEzYDaDs7Dib66xB4HigsmNiHViaWGoTaFF2LTDIU jYvsJHtTN3X2h+QQ/infV0xEuDiAZ3W7+hRUoA8m6QpWTD0G41qdrLWx9ZrL9ACiz66l VJbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=NqRsFyli/EmHyKWWTtEHVl2EkHZ2InLe+Tuh08JVv20=; b=NPi+5Ho0N1kx5yumsdP9e2CAsJpqtHyhyXTawc/eOtZ2VAuhgLtCbfO1W7OpKDezc0 I91ZUrUyQYRaZBOxhLUs1lCCRZf37bJ3ymaGP/IFSHRo2IHvytFFj3bYQCEDwHEPzk85 hRpEpT5/d22shaCyTN0Yn0rxkMI/Ilkyl/M2ICM5F91YzfSnHBTNLgZL1iv+kT6CNJqu kKW83t0uqyUv6CnL8MaLwEFSX+hmn9kpjtP6anYxouR15YZvZgR0nmQaX8Xz0/2MGlMW 1Ma7snnhaCRl2Z8CNHoPcbRhb03gcf75q7+arJNDkDgx2I/hxPFoB9pmEbW1erqmnPip d4ng== X-Gm-Message-State: AOAM533PghpVNqDO46Naz+/ylCPa3MOUET9y69nvwp5zxKh6zoXbD/+1 gY8bPYrCcD/JbC+3C/DCrN8= X-Google-Smtp-Source: ABdhPJyIdbT++t1G2DOKg8+XsiLgA1xmUy7M4yUQz3SthqO7rERv/fSULjiDtHhgXODBYjJSZ2nTIg== X-Received: by 2002:a6b:8dd0:: with SMTP id p199mr11176492iod.7.1591928735054; Thu, 11 Jun 2020 19:25:35 -0700 (PDT) Received: from ralga.knownspace (173-19-125-130.client.mchsi.com. [173.19.125.130]) by smtp.gmail.com with ESMTPSA id r18sm2443337ilt.43.2020.06.11.19.25.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2020 19:25:34 -0700 (PDT) Date: Thu, 11 Jun 2020 21:25:32 -0500 From: Justin Hibbits To: Mark Millard Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 Message-ID: <20200611212532.59f677be@ralga.knownspace> In-Reply-To: References: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <20200611164216.47f82775@ralga.knownspace> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49jl280mR7z3Vw6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=UAc04+/a; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::d43 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-1.01)[-1.010]; FREEMAIL_TO(0.00)[yahoo.com]; RECEIVED_SPAMHAUS_PBL(0.00)[173.19.125.130:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.978]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.008]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d43:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 02:25:37 -0000 On Thu, 11 Jun 2020 17:30:24 -0700 Mark Millard wrote: > On 2020-Jun-11, at 16:49, Mark Millard wrote: > > > On 2020-Jun-11, at 14:42, Justin Hibbits > > wrote: > > > > On Thu, 11 Jun 2020 14:36:37 -0700 > > Mark Millard wrote: > > > >> On 2020-Jun-11, at 13:55, Justin Hibbits > >> wrote: > >> > >>> On Wed, 10 Jun 2020 18:56:57 -0700 > >>> Mark Millard wrote: > > . . . > >> > >> > >>> That said, the attached patch effectively copies > >>> what's done in OEA6464 into OEA pmap. Can you test it? > >> > >> I'll try it once I get a chance, probably later > >> today. > >> . . . > > > > No luck at the change being a fix, I'm afraid. > > > > I verified that the build ended up with > > > > 00926cb0 bl 008e8dc8 > > 00926cb4 mr r27,r3 > > 00926cb8 addi r3,r3,36 > > 00926cbc hwsync > > 00926cc0 lwarx r25,0,r3 > > 00926cc4 li r4,0 > > 00926cc8 stwcx. r4,0,r3 > > 00926ccc bne- 00926cc0 > > 00926cd0 andi. r3,r25,128 > > 00926cd4 beq 00926ce0 > > 00926cd8 mr r3,r27 > > 00926cdc bl 008e9874 > > > > in the installed kernel. So I doubt a > > mis-build would be involved. It is a > > head -r360311 based context still. World is > > without MALLOC_PRODUCTION so that jemalloc > > code executes its asserts, catching more > > and earlier than otherwise. > > > > First test . . . > > > > The only thing that the witness kernel reported was: > > > > Jun 11 15:58:16 FBSDG4S2 kernel: lock order reversal: > > Jun 11 15:58:16 FBSDG4S2 kernel: 1st 0x216fb00 Mountpoints (UMA > > zone) @ /usr/src/sys/vm/uma_core.c:4387 Jun 11 15:58:16 FBSDG4S2 > > kernel: 2nd 0x1192d2c kernelpmap (kernelpmap) @ > > /usr/src/sys/powerpc/aim/mmu_oea.c:1524 Jun 11 15:58:16 FBSDG4S2 > > kernel: stack backtrace: Jun 11 15:58:16 FBSDG4S2 kernel: #0 > > 0x5ec164 at witness_debugger+0x94 Jun 11 15:58:16 FBSDG4S2 kernel: > > #1 0x5ebe3c at witness_checkorder+0xb50 Jun 11 15:58:16 FBSDG4S2 > > kernel: #2 0x536d5c at __mtx_lock_flags+0xcc Jun 11 15:58:16 > > FBSDG4S2 kernel: #3 0x92636c at moea_kextract+0x5c Jun 11 15:58:16 > > FBSDG4S2 kernel: #4 0x965d30 at pmap_kextract+0x98 Jun 11 15:58:16 > > FBSDG4S2 kernel: #5 0x8bfdbc at zone_release+0xf0 Jun 11 15:58:16 > > FBSDG4S2 kernel: #6 0x8c7854 at bucket_drain+0x2f0 Jun 11 15:58:16 > > FBSDG4S2 kernel: #7 0x8c728c at bucket_free+0x54 Jun 11 15:58:16 > > FBSDG4S2 kernel: #8 0x8c74fc at bucket_cache_reclaim+0x1bc Jun 11 > > 15:58:16 FBSDG4S2 kernel: #9 0x8c7004 at zone_reclaim+0x128 Jun 11 > > 15:58:16 FBSDG4S2 kernel: #10 0x8c3a40 at uma_reclaim+0x170 Jun 11 > > 15:58:16 FBSDG4S2 kernel: #11 0x8c3f70 at uma_reclaim_worker+0x68 > > Jun 11 15:58:16 FBSDG4S2 kernel: #12 0x50fbac at fork_exit+0xb0 Jun > > 11 15:58:16 FBSDG4S2 kernel: #13 0x9684ac at fork_trampoline+0xc > > > > The processes that were hit were listed as: > > > > Jun 11 15:59:11 FBSDG4S2 kernel: pid 971 (cron), jid 0, uid 0: > > exited on signal 11 (core dumped) Jun 11 16:02:59 FBSDG4S2 kernel: > > pid 1111 (stress), jid 0, uid 0: exited on signal 6 (core dumped) > > Jun 11 16:03:27 FBSDG4S2 kernel: pid 871 (mountd), jid 0, uid 0: > > exited on signal 6 (core dumped) Jun 11 16:03:40 FBSDG4S2 kernel: > > pid 1065 (su), jid 0, uid 0: exited on signal 6 Jun 11 16:04:13 > > FBSDG4S2 kernel: pid 1088 (su), jid 0, uid 0: exited on signal 6 > > Jun 11 16:04:28 FBSDG4S2 kernel: pid 968 (sshd), jid 0, uid 0: > > exited on signal 6 > > > > Jun 11 16:05:42 FBSDG4S2 kernel: pid 1028 (login), jid 0, uid 0: > > exited on signal 6 > > > > Jun 11 16:05:46 FBSDG4S2 kernel: pid 873 (nfsd), jid 0, uid 0: > > exited on signal 6 (core dumped) > > > > > > Rebooting and rerunning and showing the stress output and such > > (I did not capture copies during the first test, but the first > > test had similar messages at the same sort of points): > > > > Second test . . . > > > > # stress -m 2 --vm-bytes 1700M > > stress: info: [1166] dispatching hogs: 0 cpu, 0 io, 2 vm, 0 hdd > > : > > /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258: > > Failed assertion: "slab == extent_slab_get(extent)" : > > /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258: > > Failed assertion: "slab == extent_slab_get(extent)" ^C > > > > # exit > > : > > /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200: > > Failed assertion: "ret == sz_index2size_compute(index)" Abort trap > > > > The other stuff was similar to to first test, not repeated here. > > The updated code looks odd to me for how "m" is > handled (part of a egrep to ensure I show all the > usage of m): > > moea_protect(mmu_t mmu, pmap_t pm, vm_offset_t sva, vm_offset_t eva, > vm_page_t m; > if (pm != kernel_pmap && m != NULL && > (m->a.flags & PGA_EXECUTABLE) == 0 && > if ((m->oflags & VPO_UNMANAGED) == 0) > vm_page_aflag_set(m, > PGA_EXECUTABLE); m = PHYS_TO_VM_PAGE(old_pte.pte_lo & PTE_RPGN); > refchg = > atomic_readandclear_32(&m->md.mdpg_attrs); vm_page_dirty(m); > vm_page_aflag_set(m, > PGA_REFERENCED); > > Or more completely, with notes mixed in: > > void > moea_protect(mmu_t mmu, pmap_t pm, vm_offset_t sva, vm_offset_t eva, > vm_prot_t prot) > { > . . . > vm_page_t m; > . . . > for (pvo = RB_NFIND(pvo_tree, &pm->pmap_pvo, &key); > pvo != NULL && PVO_VADDR(pvo) < eva; pvo = tpvo) { > . . . > if (pt != NULL) { > . . . > if (pm != kernel_pmap && m != NULL && > > NOTE: m seems to be uninitialized but tested for being NULL > above. > > (m->a.flags & PGA_EXECUTABLE) == 0 && > > Note: This looks to potentially be using a random, non-NULL > value for m during evaluation of m->a.flags . > > . . . > > if ((pvo->pvo_vaddr & PVO_MANAGED) && > (pvo->pvo_pte.prot & VM_PROT_WRITE)) { > m = PHYS_TO_VM_PAGE(old_pte.pte_lo & > PTE_RPGN); > > Note: m finally is potentially initialized(/set). > > refchg = > atomic_readandclear_32(&m->md.mdpg_attrs); if (refchg & PTE_CHG) > vm_page_dirty(m); > if (refchg & PTE_REF) > vm_page_aflag_set(m, > PGA_REFERENCED); . . . > > Note: So, if m is set above, then the next loop > iteration(s) would use this then-old value > instead of an initialized value. > > It looks to me like at least one assignment > to m is missing. > > moea64_pvo_protect has pg that seems analogous to > m and has: > > pg = PHYS_TO_VM_PAGE(pvo->pvo_pte.pa & LPTE_RPGN); > . . . > if (pm != kernel_pmap && pg != NULL && > (pg->a.flags & PGA_EXECUTABLE) == 0 && > (pvo->pvo_pte.pa & (LPTE_I | LPTE_G | LPTE_NOEXEC)) == 0) > { if ((pg->oflags & VPO_UNMANAGED) == 0) > vm_page_aflag_set(pg, PGA_EXECUTABLE); > > . . . > if (pg != NULL && (pvo->pvo_vaddr & PVO_MANAGED) && > (oldprot & VM_PROT_WRITE)) { > refchg |= atomic_readandclear_32(&pg->md.mdpg_attrs); > if (refchg & LPTE_CHG) > vm_page_dirty(pg); > if (refchg & LPTE_REF) > vm_page_aflag_set(pg, PGA_REFERENCED); > > > This might suggest some about what is missing. Can you try moving the assignment to 'm' to right below the moea_pte_change() call? - Justin > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >