Date: Thu, 11 Jun 2020 21:33:20 -0700 From: Mark Millard <marklmi@yahoo.com> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: "vangyzen@freebsd.org" <vangyzen@FreeBSD.org>, svn-src-head@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, 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: <F27CB198-2169-4FB2-AA67-F8244C7D39C5@yahoo.com> In-Reply-To: <CE56E7B6-7189-41BD-9384-6E492FEA85F3@yahoo.com> References: <C24EE1A1-FAED-42C2-8204-CA7B1D20A369@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <DCABCD83-27B0-4F2D-9410-69102294A98E@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@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>
next in thread | previous in thread | raw e-mail | index | archive | help
[Yet another oddity.]
On 2020-Jun-11, at 21:05, Mark Millard <marklmi@yahoo.com> wrote:
>
> There is another oddity in the code structure, in
> that if pt was ever NULL the code would misuse the
> NULL before the test for non-NULL is made:
>
> pt = moea_pvo_to_pte(pvo, -1);
> . . .
> old_pte = *pt;
>
> /*
> * If the PVO is in the page table, update that pte as well.
> */
> if (pt != NULL) {
>
> (I'm not claiming that this explains the panic.)
There is another NULL handling oddity that the
64-bit code does not have. I'll show 64
relevant bit code first:
pg = PHYS_TO_VM_PAGE(pvo->pvo_pte.pa & LPTE_RPGN);
. . .
if (. . .&& pg != NULL &&
(pg->a.flags & PGA_EXECUTABLE) == 0 &&
. . .) {
if ((pg->oflags & VPO_UNMANAGED) == 0)
vm_page_aflag_set(pg, PGA_EXECUTABLE);
. . .
}
. . .
if (pg != NULL && . . .) {
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);
}
Note: the 2nd outer-if tests for pg != NULL, just like the
first outer-if above does. It avoids potential abuse-of-NULL
activity.
This is not true of the 32-bit code for "m":
m = PHYS_TO_VM_PAGE(old_pte.pte_lo & PTE_RPGN);
if (. . . && m != NULL &&
(m->a.flags & PGA_EXECUTABLE) == 0 &&
. . .) {
if ((m->oflags & VPO_UNMANAGED) == 0)
vm_page_aflag_set(m, PGA_EXECUTABLE);
moea_syncicache(pvo->pvo_pte.pa & PTE_RPGN,
PAGE_SIZE);
}
. . .
if ((pvo->pvo_vaddr & PVO_MANAGED) &&
(pvo->pvo_pte.prot & VM_PROT_WRITE)) {
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);
}
The &m->md.mdpg_attrs use apparently could be based on m
being NULL because there is no test for m != NULL in the
2nd outer-if. Similarly for the other uses of m in that
code block.
My guess that that the 2nd outer-if should test something
like:
. . .
if (m != NULL &&
(pvo->pvo_vaddr & PVO_MANAGED) &&
(pvo->pvo_pte.prot & VM_PROT_WRITE)) {
. . .
(Presumes that the pre-existing m != NULL tests are
necessary, something that I do not know.)
===
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?F27CB198-2169-4FB2-AA67-F8244C7D39C5>