Page MenuHomeFreeBSD

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

Authored by alc on Jun 28 2021, 6:35 PM.

Details

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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

alc requested review of this revision.Jun 28 2021, 6:35 PM

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

This revision is now accepted and ready to land.Jun 28 2021, 6:58 PM
In D30931#695853, @kib wrote:

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

Yes, I'm happy to.

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.

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.