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>
next in thread | previous in thread | raw e-mail | index | archive | help
[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:
>=20
> On 2020-Jun-16, at 19:32, Justin Hibbits <chmeeedalf at gmail.com> =
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45988F4F-56D0-4FDD-90C9-97570B2F0FCF>