arm64: a few simplications to pmap_remove_{all,write}

[alc]

Summary

Eliminate some unnecessary unlocking and relocking when we have to retry the operation to avoid deadlock. (All of the other pmap functions that iterate over a PV list already implemented retries without these same unlocking and relocking operations.)

Avoid a pointer dereference by using an existing local variable that already holds the desired value.

Eliminate some unnecessary repetition of code on a failed fcmpset. Specifically, there is no point in retesting the DBM bit because it cannot change state while the pmap lock is held.

[kib]

amd64 code is identical, do you plan to provide the same patch for it?

[alc]

In D30931#695853, @kib wrote:

amd64 code is identical, do you plan to provide the same patch for it?

Yes, I'm happy to.

[alc]

A curious difference between these functions is that pmap_remove_all() clears PGA_WRITEABLE before releasing the PV list lock but pmap_remove_write() does so after. I don't remember any reason for this difference.

[markj]

In D30931#695871, @alc wrote:

A curious difference between these functions is that pmap_remove_all() clears PGA_WRITEABLE before releasing the PV list lock but pmap_remove_write() does so after. I don't remember any reason for this difference.

We don't have any assertions about the MI synchronization required to clear PGA_WRITEABLE, though the page must be xbusied in order to set PGA_WRITEABLE (see vm_page_assert_pga_writeable()). When the object is busied instead of the page, vm_fault_soft_fast() will not install a writeable mapping if the page is already busy.

In practice, callers of pmap_remove_all() and pmap_remove_write() usually hold the sbusy lock (zap_vma_ptes() in the LinuxKPI is one exception though), and in this case I believe it is safe to clear PGA_WRITEABLE without holding the PV list lock.