Take into account race conditions in case of accessed or modified bit

emulation in fast path of data/prefetch abort common routine. Process
these bits only if related page table entries are consistent with
provided abort info. In case of inconsistency, do nothing and let
processor to signal new abort if still needed.

The mapping related to an abort may be a subject of change concurrently.
The situation is more evident on multicore machines. Mapping may be
removed on one core while being used on another one before TLB flush
happened. Memory swapping process may be an example. Or, two or more
aborts may be signaled for the same page on more cores concurrently.
While an abort on one core may cause a promotion of related mapping,
an abort on another core may be inconsistent then as related mapping
was promoted. A question is how much real the issue may be on single
core machine. However, it's better to play safe even for these machines.

This change may solve some "PT2MAP abort" panics reported rarely.
The revision of pmap_fault() was initiated thanks to stack backtrace
provided by Bob Prohaska (fbsd at www.zefox.net).

While here, INVARIANTS block was changed. The previous check had iffy
value as only one entry from many was checked from L2 page table.

Reviewed by:	mmel
MFC after:	3 weeks

0 files changed, 0 insertions, 0 deletions