Date: Sat, 27 Jun 2020 15:32:40 -0700 From: Mark Millard <marklmi@yahoo.com> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Brandon Bergren <bdragon@FreeBSD.org> 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: <45988F4F-56D0-4FDD-90C9-97570B2F0FCF@yahoo.com> In-Reply-To: <E1B78D50-D62E-43A1-9360-8C9F4B32A50F@yahoo.com> References: <C24EE1A1-FAED-42C2-8204-CA7B1D20A369@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <F5953A6B-56CE-4D1C-8C18-58D44B639881@yahoo.com> <D0C483E5-3F6A-4816-A6BA-3D2C82C24F8E@yahoo.com> <C440956F-139E-4EF7-A68E-FE35D9934BD3@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> <B1225914-43BC-44EF-A73E-D06B890229C6@yahoo.com> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <20200611164216.47f82775@ralga.knownspace> <DEA9A860-5DEE-49EE-97F1-DBDB39D5C0A3@yahoo.com> <DCB0BC72-1666-49F3-A838-B2A0D653A0C2@yahoo.com> <20200611212532.59f677be@ralga.knownspace> <1EDCA498-0B67-4374-B7CA-1ECDA8EE32AD@yahoo.com> <3605089E-7B5D-4FBA-B0D1-14B789BDF09B@yahoo.com> <CE56E7B6-7189-41BD-9384-6E492FEA85F3@yahoo.com> <F27CB198-2169-4FB2-AA67-F8244C7D39C5@yahoo.com> <20200616213205.05f365dd@titan.knownspace> <E1B78D50-D62E-43A1-9360-8C9F4B32A50F@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[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 <marklmi at yahoo.com> wrote:
>
> On 2020-Jun-16, at 19:32, Justin Hibbits <chmeeedalf at gmail.com> wrote:
>
>> (Removing hackers and current, too many cross-lists already, and those
>> interested in reading this are probably already on ppc@)
>>
>> Mark,
>>
>> 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.
>
> Sure . . . But no luck.
>
> Same crash, same backtrace related information,
> other than the "in page" figure and the "time"
> figure:
>
> panic: vm_page_free_prep: mapping flags set in page 0xd0300fc0
> cpuid = 0
> time = 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=0xf032
> r1=0xffffd810 cr=0x82000280 xer=0 ctr=0x10173810 frame=0xd2dc4a48
> KDB: enter: panic
>
> /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-9.1/gdb/inferior.c:283: internal-error: struct inferior *find_inferior_pid(int): Assertion `pid != 0' failed.
>
>
> FYI . . .
>
> (m->a.flags & (PGA_EXECUTABLE | PGA_WRITEABLE)) == 0
> is failing when (m->oflags & VPO_UNMANAGED) == 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?
>
> static bool
> vm_page_free_prep(vm_page_t m)
> {
>
> /*
> * Synchronize with threads that have dropped a reference to this
> * page.
> */
> atomic_thread_fence_acq();
>
> #if defined(DIAGNOSTIC) && defined(PHYS_TO_DMAP)
> if (PMAP_HAS_DMAP && (m->flags & PG_ZERO) != 0) {
> uint64_t *p;
> int i;
> p = (uint64_t *)PHYS_TO_DMAP(VM_PAGE_TO_PHYS(m));
> for (i = 0; i < PAGE_SIZE / sizeof(uint64_t); i++, p++)
> KASSERT(*p == 0, ("vm_page_free_prep %p PG_ZERO %d %jx",
> m, i, (uintmax_t)*p));
> }
> #endif
> if ((m->oflags & VPO_UNMANAGED) == 0) {
> KASSERT(!pmap_page_is_mapped(m),
> ("vm_page_free_prep: freeing mapped page %p", m));
> KASSERT((m->a.flags & (PGA_EXECUTABLE | PGA_WRITEABLE)) == 0,
> ("vm_page_free_prep: mapping flags set in page %p", m));
> } else {
> . . .
>
From 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 == 1 && vm_map_min(map) == sv_minuser &&
vm_map_max(map) == 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 = 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)
{
. . .
/*
* Update vm about page writeability/executability if managed
*/
PV_LOCKASSERT(pvo->pvo_pte.pa & LPTE_RPGN);
if (pvo->pvo_vaddr & PVO_MANAGED) {
if (m != 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)) == 0,
("vm_page_free_prep: mapping flags set in page %p", m));
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45988F4F-56D0-4FDD-90C9-97570B2F0FCF>