riscv pmap: add a demotion assertion

[mhorne]

Summary

Add a KASSERT to pmap_remove_write() to ensure that the page obtained
from the PV list is not a superpage where we don't expect one. An
identical KASSERT already exists in pmap_clear_modify().

This may help with debugging the panic reported in PR 250866, in which
l3 was found to be NULL. Adding this KASSERT will help narrow down the
cause of this panic the next time it occurs.

[markj]

I think pmap_page_test_mappings() and pmap_page_wired_mappings() could use a similar treatment.

[mhorne]

sys/riscv/riscv/pmap.c

3914

Slightly unrelated, but do you know why the fcmpset/retry loop is required here? pmap_clear_modify is structured similarly but performs pmap_clear_bits on the PTE instead.

Also, can it ever advance without updating oldl3?

[mhorne]

In D28109#628198, @markj wrote:

I think pmap_page_test_mappings() and pmap_page_wired_mappings() could use a similar treatment.

Sure, I can add those as well.

sys/riscv/riscv/pmap.c

3914

Forget the second question, I double checked the semantics of fcmpset.

[markj]

sys/riscv/riscv/pmap.c

3914

I believe it was done this way to handle races with the hardware setting PTE_D. We want to make sure we don't end up clearing PTE_D without observing that it was set. pmap_clear_modify() doesn't care so it can simply clear the bits.

atomic_fcmpset_* updates the old value upon failure, in contrast with atomic_cmpset_*.

[mhorne]

Add asserts to pmap_page_test_mappings() and pmap_page_wired_mappings().

Use __func__ to avoid extra line wrapping.