Date: Wed, 10 Jun 2020 18:56:57 -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: <B1225914-43BC-44EF-A73E-D06B890229C6@yahoo.com> In-Reply-To: <20200513105632.06db9e21@titan.knownspace> References: <C24EE1A1-FAED-42C2-8204-CA7B1D20A369@yahoo.com> <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-May-13, at 08:56, Justin Hibbits <chmeeedalf@gmail.com> wrote: > Hi Mark, Hello Justin. > On Wed, 13 May 2020 01:43:23 -0700 > Mark Millard <marklmi@yahoo.com> wrote: >=20 >> [I'm adding a reference to an old arm64/aarch64 bug that had >> pages turning to zero, in case this 32-bit powerpc issue is >> somewhat analogous.] >>=20 >>> . . . > ... >> . . . >>=20 >> (Note: dsl-only.net closed down, so the E-mail >> address reference is no longer valid.) >>=20 >> Author: kib >> Date: Mon Apr 10 15:32:26 2017 >> New Revision: 316679 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/316679 >>=20 >>=20 >> Log: >> Do not lose dirty bits for removing PROT_WRITE on arm64. >>=20 >> Arm64 pmap interprets accessed writable ptes as modified, since >> ARMv8.0 does not track Dirty Bit Modifier in hardware. If writable >> bit is removed, page must be marked as dirty for MI VM. >>=20 >> This change is most important for COW, where fork caused losing >> content of the dirty pages which were not yet scanned by pagedaemon. >>=20 >> Reviewed by: alc, andrew >> Reported and tested by: Mark Millard <markmi at dsl-only.net> >> PR: 217138, 217239 >> Sponsored by: The FreeBSD Foundation >> MFC after: 2 weeks >>=20 >> Modified: >> head/sys/arm64/arm64/pmap.c >>=20 >> Modified: head/sys/arm64/arm64/pmap.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/sys/arm64/arm64/pmap.c Mon Apr 10 12:35:58 >> 2017 (r316678) +++ head/sys/arm64/arm64/pmap.c Mon Apr >> 10 15:32:26 2017 (r316679) @@ -2481,6 +2481,11 @@ >> pmap_protect(pmap_t pmap, vm_offset_t sv sva +=3D L3_SIZE) { >> l3 =3D pmap_load(l3p); >> if (pmap_l3_valid(l3)) { >> + if ((l3 & ATTR_SW_MANAGED) && >> + pmap_page_dirty(l3)) { >> + >> vm_page_dirty(PHYS_TO_VM_PAGE(l3 & >> + ~ATTR_MASK)); >> + } >> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); >> PTE_SYNC(l3p); >> /* XXX: Use pmap_invalidate_range */ >>=20 >> . . . >>=20 >=20 > Thanks for this reference. I took a quick look at the 3 pmap > implementations we have (haven't check the new radix pmap yet), and it > looks like only mmu_oea.c (32-bit AIM pmap, for G3 and G4) is missing > vm_page_dirty() calls in its pmap_protect() implementation, analogous > to the change you posted right above. Given this, I think it's safe to > say that this missing piece is necessary. We'll work on a fix for > this; looking at moea64_protect(), there may be additional work needed > to support this as well, so it may take a few days. Ping? Any clue when the above might happen? I've been avoiding the old PowerMacs and leaving them at head -r360311 , pending an update that would avoid the kernel zeroing pages that it should not zero. But I've seen that you were busy with more modern contexts this last about a month. And, clearly, my own context has left pending (for much longer) other more involved activities (compared to just periodically updating to more recent FreeBSD vintages). =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?B1225914-43BC-44EF-A73E-D06B890229C6>