pmap: Fix largemap restart checks in the kernel_maps sysctl handler

[markj]

Summary

I believe my intent was to try and handle races with concurrent
modifications to the large map, but the check I added is bogus and
always fails. Instead, merely verify that the next page table page is
mapped into the direct map.

[markj]

@rpokala could you please see if this patch fixes the hang you see when reading vm.pmap.kernel_maps while an nvdimm is mapped?

[kib]

I do not quite understand the change.

Typical nvdimm SPA is at very high physical address, definitely beyond dmaplimit. If PG_PS bit is not set then pa should be a page table page phys address, If PG_PS bit is set, then pa >= dmaplimit is probably always true.

Why it is not enough to test for PG_V, which is already done?

[markj]

In D28922#647562, @kib wrote:

I do not quite understand the change.

Typical nvdimm SPA is at very high physical address, definitely beyond dmaplimit. If PG_PS bit is not set then pa should be a page table page phys address, If PG_PS bit is set, then pa >= dmaplimit is probably always true.

Oh, sigh, the real problem is that the check must come after the PG_PS check, not before.

Why it is not enough to test for PG_V, which is already done?

The PTP may be freed and reused at any point, so PG_V being set doesn't ensure that we can descend to the next level. This is not true of other maps in the kernel page tables.

[markj]

Move the check, restore the original condition, add comments.

[rpokala]

In D28922#647557, @markj wrote:

@rpokala could you please see if this patch fixes the hang you see when reading vm.pmap.kernel_maps while an nvdimm is mapped?

Much better! It emitted several thousand lines, including the "Large map", and it was virtually instantaneous.

Thank you for figuring this out! (And for MFCing the CTLFLAG_SKIP change.)