From owner-freebsd-current@freebsd.org Thu Jun 11 21:36:47 2020 Return-Path: Delivered-To: freebsd-current@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 ACA51341E37 for ; Thu, 11 Jun 2020 21:36:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 49jcct57drz4Ql3 for ; Thu, 11 Jun 2020 21:36:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oMlrzEkVM1n0fQy94q7okPpe3jwvUEdPQCVGTq7two5lUxYwGoA00PDhSFfvZEV fL8tTKl9DnO7erx4D7Fk1gCOyvv_Wlar7eaZKlyH2.1fPy2P1f1RxnI_O1H2L_7q5H_MiUU4o1by fS31gZjNhXHLCtFStH9Yu2Zua59G7ZOQp9KILYuPKO2HfQSwrkjDxe0HxHhrWQXLkyAEpGOCrdPB tixhqaTKEZJTJYpRRVxzlNHj6hU.lx5GpPxCP4Oa.GRJi1oPYz.3ue_gxDTcoOACRZUkcj5h1E25 _yYhxJH02JqlneJC0kybfKXMRh9UllX36TUV7CZKrWluqLOTFjDRk8cDjhymRxbQJaid6I9abfPf hWVKGITG5XAj.91xH9jldjCL1vvlhfQQBiA7nCJOF59VJUImr6qle1Ly0f0Df8BIV5hcOg8hQ1bd dYsWynkfcP7n0bgMzflkQ823.oFjZ9X6WJhk.Do6h6E06NEF0uiQrTwPvQD0icPV6Byvdix14tOY mtuKVe6joAOd74Cu0eX6pjytREg5P94kRhZAOxrWclD7xM026vi3l05ZiW7F1rde.njtwd5MojU_ wBZC_eCI4jIMWwB_bbNjSFccu3Nki.XCLMhqO0kVyK0sQKjn.ZXSDDGQ.q1M1f34hbarWwA0na.P vK.S0ueW6.gnOQVGwOtwR184YGzhhFDD889cZ9PCnSWDdQMr83zS8tdKkrDPKZ4v1kxBNYjko6qH Misr0ln9ygcAPQEYGY0ynssLLaWq0hKMU3.ZzrPThigjvl2ZoT9qG1vo6ot_WitUm_j_whd1O3AE qsMXZyTN__NPXURKQeRTc1AuYZITSWHKbw0D8IzA1AH0Ku49oBP6icue5oBwwR5uZHSK22.n6Sg7 jDZ9udIgpEwjEwKqvMp84Kr9iMnKuFV0W5xp9_.2AnLlYsGj8J0sLA8QaPckzgpPw.L6r6ixTS8K r1WgMPWRdafAtd.65Sk3TEFhhcIjTnWtcgaPFDjykQ42Y.r8oxsFKV4fWdeUjfzYCEYvZdSAHiCw ICEvnScN9bvsplu_dIdhEbp2rAE5Da1uMQ1eWosMR9_caBjSWYcEq9iyR9EC4LWS6HRzShR_JJdk 5ZC_V05t70_9.JmxQ84i1WsLpKlNQ0KKp3Ioyyp2rmkcitmx8U8A72yasgWp1KaPCthHPqQCQKgu gc4cN1PxG1DGEQim.1x_YEbVT271OE17aoUZjqlah6ityZ_5r3s7BGWyBIf0RjNSdBekz2ylv4DT FD1fuoMYK747RPLTFgM4lUeunGOx_yYZ86MEFBSi5EGyJIwTwLXzNoKCJJ5mfnp2EM6JaQ5GzKa0 zsCYCLnj3rXizkTfIe8BYkvnUpAAW5js27jYX7MmCgKMfMazh4p8K4fWKkKuvat3sqQjlk8kGSFb wyi2uqxZeUebZ4YaDKpN57AKWO5TN Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jun 2020 21:36:44 +0000 Received: by smtp416.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fdfd3dccc9714f1e32d72e6a803eab89; Thu, 11 Jun 2020 21:36:39 +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: <20200611155545.55526f7c@ralga.knownspace> Date: Thu, 11 Jun 2020 14:36:37 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <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> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jcct57drz4Ql3 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.14 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.63)[-0.635]; 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.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 21:36:47 -0000 On 2020-Jun-11, at 13:55, Justin Hibbits = wrote: > On Wed, 10 Jun 2020 18:56:57 -0700 > Mark Millard wrote: >=20 >> On 2020-May-13, at 08:56, Justin Hibbits = wrote: >>=20 >>> Hi Mark, =20 >>=20 >> Hello Justin. >=20 > Hi Mark, Hello again, Justin. >>=20 >>> On Wed, 13 May 2020 01:43:23 -0700 >>> Mark Millard 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 >>> ... =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 >>> 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. =20 >>=20 >> Ping? Any clue when the above might happen? >>=20 >> 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. >>=20 >> 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). >>=20 >> . . . >>=20 >=20 > Sorry for the delay, I got sidetracked with a bunch of other > development. > I did install a newer FreeBSD on my dual G4 and couldn't > see the problem. How did you test? In my context it was far easier to see the problem with builds that did not use MALLOC_PRODUCTION. In other words: jemalloc having its asserts tested. The easiest way I found to get the asserts to fail was to do (multiple processes (-m) and totaling to more than enough to force paging/swapping): stress -m 2 --vm-bytes 1700M & (Possibly setting up some shells first to potentially later exit.) Normally stress itself would hit jemalloc asserts. Apparently the asserts did not stop the code and it ran until a failure occurred (via dtv=3D0x0). I never had to manually stop the stress processes. If no failures during, then exit shells that likely were swapped out or partially paged out during the stress run. They hit jemalloc asserts during their cleanup activity in my testing. > That said, the attached patch effectively copies > what's done in OEA6464 into OEA pmap. Can you test it? I'll try it once I get a chance, probably later today. I gather from what I see that moea64_protect did not need the changes that you originally thought might be required? I only see moea_protect changes in the patch. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)