: This would explain why messing with the pmap_remove_all() case does
: not do what we expect -- I suspect that routine is not being called
: at all in certain cases.
:
: I have not found the case where the pmap gets cleared without being
: flushed yet but when I force the flush in pmap_enter(), it seems to
: stop the crashes (but I can't be 100% sure because I had to mess
: around with that file descriptor program to get it to crash the first
: time).
Is it possible that a speculative read by the cpu is causing the TLB
to load the invalid pte entry after we have cleared it but before
we have created a new entry? This would not cause a fault, but it
would load the TLB and cause a problem when we later initialize the
pte but fail to invalpg1 the VA.
A sequence like this:
pmap_remove_all() called on pa
tlb at VA flushed
(something happens to cause the cpu to load the tlb at VA without
faulting).
pmap_enter() called with new pte (kernel memory is freed and
then later allocated again). Old contents was 0 so pmap_enter()
does not flush the tlb at VA. TLB still contains the invalid pte.
System resumes operation, but invalid tlb entry for VA is still
in the tlb. Bewm.
Personally speaking I think we should simply invalidate the
tlb at VA whenever we modify a pte, no matter what the original
contents of that pte was. For both 3.x and 4.x.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
