User Details
- User Since
- Apr 17 2020, 10:28 PM (241 w, 4 d)
Jul 10 2021
Oof, that erratum; thanks for the heads up. I guess that means there should be some mechanism to replace (other uses of) sfence_vma_page with sfence_vma on effected chips? I think specifically for this case, though, it's fine: the ITLB may still fill with the old entry before this sfence.vma, but pmap_fault only changes A/D here. I suppose there could be an extra fault delivered from caching an A-clear PTE (if the load is done now by some very prognosticative speculation, say) despite that pmap_fault just set it, and I imagine the ITLB doesn't care about D at all. This extra fault will land us here again and cause another sfence.vma and even if the ITLB simultaneously refills the PTE about to be sfence.vma-ed, it will definitely see the A-set PTE from the last go around. That is, I don't think this makes anything worse.
Jul 9 2021
Jun 23 2021
Jun 22 2021
Jun 5 2021
Yes, this does look like it fixes the original panic I saw as well as my hand-written test. Thanks!
Jun 4 2021
Jun 2 2021
Thanks to @markj for the explanation; this is an incorrect fix.
Jun 1 2021
May 30 2021
Well, for whatever it's worth, the reproducer seems not to panic on amd64, which is a little surprising as I don't see any special handling for setting PG_M on !VPO_UNMANAGED, PG_RW, psind=1 pages in pmap_enter(), and I'd have thought the MI layers were doing the same thing on both.
May 29 2021
Just the casts now, no function or structure type changes. This appears to pass muster locally.
May 16 2021
Apr 27 2021
Dec 7 2020
Dec 3 2020
Oct 8 2020
Renamed macro as per mhorne's feedback
Sep 30 2020
Jul 17 2020
Incorporate feedback from @mhorne
Jul 2 2020
Sorry, newbie learning way around arc. Seems it grabbed an unintended commit.
Slightly less code motion; tested using qemu "-append -s" on FreeBSD machine I'd forgotten about.
Revised in light of jrtc27's comments. Unfortunately, I lack a FreeBSD box to build and test this on (sorry, CheriBSD builds fine and I didn't think about our being lagged relative to upstream); perhaps someone who does would be so kind as to let me know if I've broken something?
Jul 1 2020
Feedback from mhorne.
Yes, that's a fine "Submitted by".
Jun 30 2020
Apr 24 2020
More respose to markj feedback
Apr 23 2020
Revised version as per markj's feedback
Apr 21 2020
Now without D24523 included