Page MenuHomeFreeBSD

kstack: Fix iterator usage in vm_thread_stack_create()
ClosedPublic

Authored by markj on Oct 8 2025, 2:03 PM.
Tags
None
Referenced Files
F164749392: D52982.id.diff
Mon, Aug 3, 3:27 PM
F164702771: D52982.id164353.diff
Mon, Aug 3, 6:32 AM
F164695226: D52982.id163777.diff
Mon, Aug 3, 5:36 AM
Unknown Object (File)
Sun, Aug 2, 5:08 AM
Unknown Object (File)
Fri, Jul 31, 6:45 AM
Unknown Object (File)
Fri, Jul 31, 1:45 AM
Unknown Object (File)
Wed, Jul 29, 4:54 PM
Unknown Object (File)
Wed, Jul 29, 4:53 PM
Subscribers

Details

Summary

After commit 7a79d0669761 we no longer hold the VM object lock when
initializing or advancing the domainset iterator in
vm_thread_stack_create().

We could lift the lock out of vm_thread_stack_back() but that poses
complications since we cannot allocate KVA with a VM object lock held.

Instead of overridding the object's iterator, just borrow that of the
current thread. Kernel stacks are basically always allocated with a
DOMAINSET_POLICY_PREFER policy, so it's not very important to maintain a
global iterator for round-robin allocation.

As a part of this, fix up flag handling: make sure we handle
M_NOWAIT/M_WAITOK from the caller. Delete a comment in vm_thread_new()
which refers to a non-existent consideration (stack swapping has been
removed). I suspect vm_thread_new() can use M_WAITOK but opted not to
make that change here.

Fixes: 7a79d0669761 ("vm: improve kstack_object pindex calculation to avoid pindex holes")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Oct 8 2025, 2:03 PM
This revision is now accepted and ready to land.Oct 8 2025, 4:19 PM

Please add Reported by: olce at commit, thanks!