i386 pmap: allocate leaf page table page for wired userspace superpages

[bnovkov]

Summary

This patch fixes a syzkaller issue regarding wired userspace superpages by allocating a leaf page table page for wired userspace superpages.

The original issue is an edge case that creates an unmapped, wired region in userspace. Subsequent faults on this region can trigger wired superpage creation, leading to a panic upon demotion as the pmap does not create a leaf page table page for the wired superpage. D19670 fixed this by disallowing preemptive creation of wired superpage mappings, but that fix is currently interfering with an ongoing effort of speeding up vm_map_wire for large, contiguous entries (e.g. bhyve wiring guest memory) .

[markj]

sys/i386/i386/pmap.c

4035

The amd64 patch doesn't zero the PTP here, and I believe that's correct. Why exactly do we need to zero the page here?

4058

The indentation here should be by four spaces.

[bnovkov]

Address @markj 's comments.

[bnovkov]

sys/i386/i386/pmap.c

4035

That was an unintentional slipup, thank you for catching that.

[alc]

sys/i386/i386/pmap.c

4035

Because i386 doesn't have 34eeabff5a8636155bb02985c5928c1844fd3178, so zeroing is necessary.

[alc]

@markj I think that you should apply 34eeabff5a8636155bb02985c5928c1844fd3178 to i386 and riscv. Otherwise, I suspect that there will be assertion failures in places like pmap_remove_pde():

KASSERT(vm_page_all_valid(mpte),
    ("pmap_remove_pde: pte page not promoted"));

[bnovkov]

Address @alc 's comments.

[alc]

In D41635#955565, @bojan.novkovic_fer.hr wrote:

Address @alc 's comments.

Unfortunately, zeroing the page table page won't prevent some of the assertions from misfiring. I've started preparing a variant of 34eeabff5a8636155bb02985c5928c1844fd3178 and some related changes to i386. Once that is committed, you won't need to zero the page table page and assertions will not be a problem.

[alc]

I've just committed 902ed64fecbe which eliminates the need for zeroing the PTP and the possibility of an assertion failure if you pass the same arguments to pmap_insert_pt_page() as you did on amd64. pmap_insert_pt_page() now has the needed extra argument.

[markj]

In D41635#954945, @alc wrote:

@markj I think that you should apply 34eeabff5a8636155bb02985c5928c1844fd3178 to i386 and riscv. Otherwise, I suspect that there will be assertion failures in places like pmap_remove_pde():

KASSERT(vm_page_all_valid(mpte),
    ("pmap_remove_pde: pte page not promoted"));

I was away for a few weeks and am only now getting caught up. I can spend some time on the riscv pmap if you aren't already working on it.

@bojan.novkovic_fer.hr if you have time, could you please try the test case I added in commit 8f26ed01bd74aab21309ac04ae1d1368a6346c90? That is how I found the bug in the amd64 patch. Note that for the test to be effective, you need to revert commit 64087fd7f372d70a0aaaeb02ffd3438720923534. Once all of your pmap patches land, I believe we can revert that commit.

[bnovkov]

Address @alc 's comments.

[bnovkov]

In D41635#957353, @alc wrote:

I've just committed 902ed64fecbe which eliminates the need for zeroing the PTP and the possibility of an assertion failure if you pass the same arguments to pmap_insert_pt_page() as you did on amd64. pmap_insert_pt_page() now has the needed extra argument.

That is great, thank you for your effort!

In D41635#957607, @markj wrote:

@bojan.novkovic_fer.hr if you have time, could you please try the test case I added in commit 8f26ed01bd74aab21309ac04ae1d1368a6346c90? That is how I found the bug in the amd64 patch. Note that for the test to be effective, you need to revert commit 64087fd7f372d70a0aaaeb02ffd3438720923534. Once all of your pmap patches land, I believe we can revert that commit.

No problem, I'm a bit swamped at the moment but I'll run it within the next couple of days.

[alc]

In D41635#957607, @markj wrote:

In D41635#954945, @alc wrote:

@markj I think that you should apply 34eeabff5a8636155bb02985c5928c1844fd3178 to i386 and riscv. Otherwise, I suspect that there will be assertion failures in places like pmap_remove_pde():

KASSERT(vm_page_all_valid(mpte),
    ("pmap_remove_pde: pte page not promoted"));

I was away for a few weeks and am only now getting caught up. I can spend some time on the riscv pmap if you aren't already working on it.

I am not.

[bnovkov]

@markj I tried the new mlock superpage test case, the patch didn't cause a panic.

[alc]

@markj Are you overloaded? Should I commit this?

[markj]

In D41635#961050, @alc wrote:

@markj Are you overloaded? Should I commit this?

Done now, I'm sorry for the delay.