On 19/02/2026 08:03, Samuel Thibault wrote:
Michael Kelly, le jeu. 19 févr. 2026 07:52:41 +0000, a ecrit:
I think that something
is going wrong and I'll be looking into it over the days ahead.
One instance that occurred whilst building haskell-hedgehog:
login: panic ../vm/vm_page.c:1618: vm_page_alloc_pa: vm_page: privileged
thread unable to allocate page
Debugger invoked: panic
Kernel Breakpoint trap, eip 0xffffffff8100c956, code 0, cr2 ffffffffb2e19b00
Stopped at Debugger+0x15: TODO
Debugger(...)+0x15
Panic(...)+0xb8
vm_page_alloc_pa(...)+0x2da
vm_page_convert(...)+0x57
vm_fault_page(...)+0x832
vm_fault(...)+0x5d0
vm_fault_wire(...)+0x75
vm_map_pageable_scan(...)+0x154
vm_map_protect(...)+0x1c5
So it's inside a vm_map_lock() indeed.
I'm thinking that on non-vm_privileged threads, we could perhaps
make vm_map_lock() block as long as memory is low. The vm_privilege
escalation there is meant to make sure the section progresses in case we
got memory low in between, but if memory is already low on entry, we can
just make the caller block.
I'll have a think about this.
I should also mention that I have also seen this panic scenario whilst
running a recent gnumach using the previous Linux disc driver (ie. not
rumpdisk) although the points you are making do not apply exclusively to
rumpdisk, of course.
Regards,
Mike.
