I don't see why this is sufficient. If the unlocked translation attempt fails, e.g., because the mapping is being promoted or demoted a second time, we may still attempt to acquire a mutex in a scenario where that is not allowed.

Can we use the same trick that pmap_kextract() does to identify mappings that are transiently invalid?

In D21685#473043, @markj wrote:

I don't see why this is sufficient. If the unlocked translation attempt fails, e.g., because the mapping is being promoted or demoted a second time, we may still attempt to acquire a mutex in a scenario where that is not allowed.

Can we use the same trick that pmap_kextract() does to identify mappings that are transiently invalid?

Yes, I believe so. A "translation fault" only says that the page table walk encountered an invalid entry. It does not say anything about protection, and so the lock-free software page table walk that I wrote for pmap_kextract() should suffice.

Here is a patch based on Mark's suggestion.

Index: arm64/arm64/pmap.c
===================================================================
--- arm64/arm64/pmap.c  (revision 352346)
+++ arm64/arm64/pmap.c  (working copy)
@@ -5810,13 +5810,21 @@ pmap_fault(pmap_t pmap, uint64_t esr, uint64_t far
        case ISS_DATA_DFSC_TF_L1:
        case ISS_DATA_DFSC_TF_L2:
        case ISS_DATA_DFSC_TF_L3:
+               if (pmap == kernel_pmap) {
+                       /*
+                        * The translation fault may have occurred within a
+                        * critical section.  Therefore, we must determine if
+                        * the address was invalid due to a break-before-make
+                        * sequence without acquiring the pmap lock.
+                        */
+                       if (pmap_kextract(far) != 0)
+                               rv = KERN_SUCCESS;
+                       break;
+               }
                PMAP_LOCK(pmap);
                /* Ask the MMU to check the address */
                intr = intr_disable();
-               if (pmap == kernel_pmap)
-                       par = arm64_address_translate_s1e1r(far);
-               else
-                       par = arm64_address_translate_s1e0r(far);
+               par = arm64_address_translate_s1e0r(far);
                intr_restore(intr);
                PMAP_UNLOCK(pmap);
 

@alc Can you commender this and update with that patch?

As an aside, I want to ask why pmap_update_entry() both blocks interrupts and performs critical_enter()? Doesn't the former suffice?

An often forgotten fact is that there are parts of the kernel address space that are swappable, the exec and pipe submaps. If a page from one of these areas gets written out to swap space, it will be write protected. If it is then written to before it is reclaimed by the page daemon, there will be a call to pmap_enter() that essentially does a break-before-make sequence, but without blocking interrupts or using pmap_update_entry()'s "trick" for marking the mapping invalidation as transient.

In such a case, a concurrent access that occurs while the mapping is invalid will no longer be recognized by pmap_fault() as a transient fault, so we will wind up calling vm_fault() and pmap_enter() again. In other words, pmap_kextract() won't recognize the mapping change as transient, whereas before acquiring the kernel pmap's lock would have had pmap_fault() wait until the change had completed before rechecking the address. I don't think that this repeated call to vm_fault() and pmap_enter() is going to do any harm.