From owner-freebsd-ppc@freebsd.org Sat Jun 27 22:32:49 2020 Return-Path: Delivered-To: freebsd-ppc@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 8C49C35E476 for ; Sat, 27 Jun 2020 22:32:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49vT683WCtz4Y76 for ; Sat, 27 Jun 2020 22:32:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5UgYI18VM1lL98L4FzE9Kn56egXI4l2I5MM_Y7fQp6VumUrZBxcxS4rukvtRHAh cazhXGQ173UcQzsI_.01lOn0euD0PYf5IG7gBGXd5DJkGyoLSzKw2xZOFxoAS_7iwtzru3T_8oK8 qEt_lqY3IR2.8H.if0B35RDsRcP_Xx7YWzd0U.Ax.fuNn_hZUNwmTNDrSMjPqdnksIfyejRGAr8V A882vNVCAfnPgu83J1jl8DjKO0LGSEdr5rt9BXgqZHsS44eXqHj0QjnUlHaR2OR1RymHbgTSmVkZ Cd.dXsjbUzMYnWWSKp6wqQA52SPR3B6Ae.OVGmklXmQAN2INuZqtX0KpDf35xGBCL.2woyTIi2Fw bERCTTzG423.3f4wR50FQ5SuIJjGVY4ICaudcWMLyp16FNKbeaYKAMRUvrKwHCw3KtQIsjEI2jxa JDPnZUnjz6Q_V1b9ODAClmTBxGsVj5kw._yE2s.VjzYvjYpsMD5TGj1t5FZZCExk1jHj0fmQ3Dmg ndS3XvJqed95o1uFG4Vic5HFb5hCL.JZSF3USooGocdbggnDBQq6J242Qim21hNSSpS8Dq25692K _ULMy5QOVfEcrZVjGII.cJIK6BF62D4IzJlB.qeOmhshrrLXYsPG3GmGvyLglSxB9VRBNc_4XS1F p1z_tW1lMhOuWGBu1bOIjnBsqnN0xDKjzejMvfEyt23iKxT4EqOWKqso7UeiJiVbBjGQQG5CPdfB JvuOCtwW22EF1J9XscT6mTQKJVjB4yXm5hEmBZw24BSoOv.g2rUedj7AiGpOxFz94XoouXW_QG4S yBW9OAJMbyOhycgoMnQwXlu_RNi5SyYqKpZ7TIsKUJE5uJsoZzLZq0nWrd8R9NZy8Ujbyo67ZPm7 Rsfl80HNcFIXmd4jkWa.p2WejzfNQNG3NfjOo1ylIjpyY5C_J.3NDL4iCQ5LzsUBY3R6fEVfZC_I R7YS7ZWWzdlmedBjhEQW2xPERYhzEMIPYzgxRaXuFjQPe7kgUIpRshnZrppJrGhyf3IrOiVpPD4h MIjh1TQUX87bakgJkhLpV8K4ua6ka6R5kJzYwnl_Blv6QAGVyGceT12PuOXof7SG.bP4J4m7Za1P 2zH5QEwjFNPRyRgBVmtqo9m_gVG1HXUjCVtfrFIOaeufCcK2O396utIv48RROtF9o6FnqqQvBBnn UDTiQCBL1pv.iVEmWGYiKAmwazOrLl0yclNSn3.KcZnhbuahAcm6iJop.DdPlRQPl7UXkxAQBmxG n0h6o1g_Y0jDpXOC3GXH9qFSEWCJmAhz1b2PPMenmcChu0ZTPSnOHINHej3gklWxzk3WiDrKkREa 5I9mcj3zCsmTiZ5ns_A2FQFBrkjawRDDBLLjFfyBUQG5FskgB3TQXHVK8tx5J1qa8VutDWkfbvxv S38Am.1cwsBS9r0ip1YtWvnbh6zGnhPo.prHY0nMjdplU1D84qaZqxJRC Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Jun 2020 22:32:43 +0000 Received: by smtp414.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ebcba1b990922dd4d79544d4573d53bf; Sat, 27 Jun 2020 22:32:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) 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 From: Mark Millard In-Reply-To: Date: Sat, 27 Jun 2020 15:32:40 -0700 Cc: FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <45988F4F-56D0-4FDD-90C9-97570B2F0FCF@yahoo.com> References: <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> <20200611212532.59f677be@ralga.knownspace> <1EDCA498-0B67-4374-B7CA-1ECDA8EE32AD@yahoo.com> <3605089E-7B5D-4FBA-B0D1-14B789BDF09B@yahoo.com> <20200616213205.05f365dd@titan.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49vT683WCtz4Y76 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.61 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.13)[-1.128]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.018]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.96)[-0.960]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.148:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 22:32:49 -0000 [I found a cause of the crash problem for the patched code, or so I expect. More missing code.] On 2020-Jun-16, at 20:23, Mark Millard wrote: >=20 > On 2020-Jun-16, at 19:32, Justin Hibbits = wrote: >=20 >> (Removing hackers and current, too many cross-lists already, and = those >> interested in reading this are probably already on ppc@) >>=20 >> Mark, >>=20 >> Can you try this updated patch? Again, I've only compiled it, I >> haven't tested it, so it may also explode. However, it more closely >> mimics exactly what moea64 does. >=20 > Sure . . . But no luck. >=20 > Same crash, same backtrace related information, > other than the "in page" figure and the "time" > figure: >=20 > panic: vm_page_free_prep: mapping flags set in page 0xd0300fc0 > cpuid =3D 0 > time =3D 1592362496 > KDB: stack backtrace: > 0xd2dc4340: at kdb_backtrace+0x64 > 0xd2dc43a0: at vpanic+0x208 > 0xd2dc4410: at panic+0x64 > 0xd2dc4450: at vm_page_free_prep+0x348 > 0xd2dc4470: at vm_page_free_toq+0x3c > 0xd2dc4490: at vm_page_free+0x20 > 0xd2dc44a0: at vm_object_collapse+0x4ac > 0xd2dc4510: at vm_object_deallocate+0x430 > 0xd2dc4550: at vm_map_process_deferred+0xec > 0xd2dc4570: at vm_map_remove+0x12c > 0xd2dc4590: at exec_new_vmspace+0x20c > 0xd2dc45f0: at exec_elf32_imgact+0xa70 > 0xd2dc46a0: at kern_execve+0x600 > 0xd2dc4910: at sys_execve+0x84 > 0xd2dc4970: at trap+0x748 > 0xd2dc4a10: at powerpc_interrupt+0x178 > 0xd2dc4a40: user SC trap by 0x100d71f8: srr1=3D0xf032 > r1=3D0xffffd810 cr=3D0x82000280 xer=3D0 ctr=3D0x10173810 = frame=3D0xd2dc4a48 > KDB: enter: panic >=20 > /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-9.1/gdb/inferior.c:283: = internal-error: struct inferior *find_inferior_pid(int): Assertion `pid = !=3D 0' failed. >=20 >=20 > FYI . . . >=20 > (m->a.flags & (PGA_EXECUTABLE | PGA_WRITEABLE)) =3D=3D 0 > is failing when (m->oflags & VPO_UNMANAGED) =3D=3D 0 holds in > vm_page_free_prep. See the last KASSERT in the code > quoted below. Does this suggest the lack of someplace > not clearing some flags in m->a.flags that should be > doing so? >=20 > static bool > vm_page_free_prep(vm_page_t m) > { >=20 > /* > * Synchronize with threads that have dropped a reference to = this > * page. > */ > atomic_thread_fence_acq(); >=20 > #if defined(DIAGNOSTIC) && defined(PHYS_TO_DMAP) > if (PMAP_HAS_DMAP && (m->flags & PG_ZERO) !=3D 0) { > uint64_t *p; > int i; > p =3D (uint64_t *)PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m)); > for (i =3D 0; i < PAGE_SIZE / sizeof(uint64_t); i++, = p++) > KASSERT(*p =3D=3D 0, ("vm_page_free_prep %p = PG_ZERO %d %jx", > m, i, (uintmax_t)*p)); > } > #endif > if ((m->oflags & VPO_UNMANAGED) =3D=3D 0) { > KASSERT(!pmap_page_is_mapped(m), > ("vm_page_free_prep: freeing mapped page %p", m)); > KASSERT((m->a.flags & (PGA_EXECUTABLE | PGA_WRITEABLE)) = =3D=3D 0, > ("vm_page_free_prep: mapping flags set in page %p", = m)); > } else { > . . . >=20 =46rom what I can tell there is another 32-bit vs. 64 bit difference for the following code that involves 32-bit not using vm_page_aflag_clear(???,PGA_WRITEABLE | PGA_EXECUTABLE) where 64-bit does involve such. Starting a trace of the issue at exec_new_vmspace . . . int exec_new_vmspace(struct image_params *imgp, struct sysentvec *sv) { . . . if (vmspace->vm_refcnt =3D=3D 1 && vm_map_min(map) =3D=3D = sv_minuser && vm_map_max(map) =3D=3D sv->sv_maxuser && cpu_exec_vmspace_reuse(p, map)) { shmexit(vmspace); pmap_remove_pages(vmspace_pmap(vmspace)); vm_map_remove(map, vm_map_min(map), vm_map_max(map)); . . . The "pmap_remove_pages(vmspace_pmap(vmspace))" before the vm_map_remove use has a very different handling for 64-bit (does something) vs. 32-bit (no-op) . . . moea64_remove_pages is (and eventually involves vm_page_aflag_clear): void moea64_remove_pages(mmu_t mmu, pmap_t pm) { . . . while (!SLIST_EMPTY(&tofree)) { pvo =3D SLIST_FIRST(&tofree); SLIST_REMOVE_HEAD(&tofree, pvo_dlink); moea64_pvo_remove_from_page(mmu, pvo); free_pvo_entry(pvo); } } where moea64_pvo_remove_from_page involves vm_page_aflag_clear(????,PGA_WRITEABLE | PGA_EXECUTABLE) via: static inline void moea64_pvo_remove_from_page_locked(mmu_t mmu, struct pvo_entry *pvo, vm_page_t m) { =20 . . .=20 /* * Update vm about page writeability/executability if managed */ PV_LOCKASSERT(pvo->pvo_pte.pa & LPTE_RPGN); if (pvo->pvo_vaddr & PVO_MANAGED) { if (m !=3D NULL) { LIST_REMOVE(pvo, pvo_vlink); if (LIST_EMPTY(vm_page_to_pvoh(m))) vm_page_aflag_clear(m, PGA_WRITEABLE | PGA_EXECUTABLE); } } . . . } But 32-bit has/uses: static void mmu_null_remove_pages(mmu_t mmu, pmap_t pmap) { return; } so it does not involve: vm_page_aflag_clear(????,PGA_WRITEABLE | PGA_EXECUTABLE) but apparently should involve such in order to pass: KASSERT((m->a.flags & (PGA_EXECUTABLE | PGA_WRITEABLE)) = =3D=3D 0, ("vm_page_free_prep: mapping flags set in page %p", = m)); =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)