I can reliably trigger a kassert with rctl + jails: Grab FreeBSD-16.0-CURRENT-amd64-ufs.qcow2.xz or similar. Set tunable kern.racct.enable="1" $ pkg install stress $ rctl -a jail:test:maxproc:deny=100 $ jail -c name=test command=stress -i 1000 stress: info: [1387] dispatching hogs: 0 cpu, 1000 io, 0 vm, 0 hdd panic: /usr/src/sys/kern/kern_proc.c:247: proc_dtor: Empty stailq 0xfffffe005118ef90->stqh_last is 0, not head's first field address cpuid = 3 time = 1765130031 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0054df2b10 vpanic() at vpanic+0x136/frame 0xfffffe0054df2c40 panic() at panic+0x43/frame 0xfffffe0054df2ca0 proc_dtor() at proc_dtor+0x29f/frame 0xfffffe0054df2ce0 uma_zfree_arg() at uma_zfree_arg+0xaa/frame 0xfffffe0054df2d30 fork1() at fork1+0x5b3/frame 0xfffffe0054df2da0 sys_fork() at sys_fork+0x54/frame 0xfffffe0054df2e00 amd64_syscall() at amd64_syscall+0x169/frame 0xfffffe0054df2f30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0054df2f30 --- syscall (2, FreeBSD ELF64, fork), rip = 0x823c08eba, rsp = 0x820e7e538, rbp = 0x820e7e5e0 --- KDB: enter: panic [ thread pid 1387 tid 100343 ] Stopped at kdb_enter+0x33: movq $0,0x1217422(%rip) db>
https://reviews.freebsd.org/D54215
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=026d962ef14dafe19fa73361bea6dcc95f141dfa commit 026d962ef14dafe19fa73361bea6dcc95f141dfa Author: Dag-Erling Smørgrav <des@FreeBSD.org> AuthorDate: 2025-12-14 13:16:22 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2025-12-14 13:16:37 +0000 proc: Fix proc_init / proc_dtor ordering issues * Move the initialization of p_ktr into proc_init() and make the check in proc_dtor() unconditional. Prior to this, it was possible to fail and invoke proc_dtor() after the first thread had been created (which was the condition for checking p_ktr in proc_dtor()) but before p_ktr had been initialized. * Move the p_klist initialization in fork1() past the last possible failure point so we don't have to free it on failure. We didn't, which meant we were leaking a knlist every time we failed to fork due to hitting the resource limit. PR: 291470 MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54215 sys/kern/kern_fork.c | 4 ++-- sys/kern/kern_proc.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=faac79511757177ee51e44af0a4e57cee742f390 commit faac79511757177ee51e44af0a4e57cee742f390 Author: Dag-Erling Smørgrav <des@FreeBSD.org> AuthorDate: 2025-12-14 13:16:22 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2025-12-19 18:05:44 +0000 proc: Fix proc_init / proc_dtor ordering issues * Move the initialization of p_ktr into proc_init() and make the check in proc_dtor() unconditional. Prior to this, it was possible to fail and invoke proc_dtor() after the first thread had been created (which was the condition for checking p_ktr in proc_dtor()) but before p_ktr had been initialized. * Move the p_klist initialization in fork1() past the last possible failure point so we don't have to free it on failure. We didn't, which meant we were leaking a knlist every time we failed to fork due to hitting the resource limit. PR: 291470 MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54215 (cherry picked from commit 026d962ef14dafe19fa73361bea6dcc95f141dfa) sys/kern/kern_fork.c | 4 ++-- sys/kern/kern_proc.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=00bdb832fd5def6dee43773d93a4f69c8db44643 commit 00bdb832fd5def6dee43773d93a4f69c8db44643 Author: Dag-Erling Smørgrav <des@FreeBSD.org> AuthorDate: 2025-12-14 13:16:22 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2025-12-19 18:06:00 +0000 proc: Fix proc_init / proc_dtor ordering issues * Move the initialization of p_ktr into proc_init() and make the check in proc_dtor() unconditional. Prior to this, it was possible to fail and invoke proc_dtor() after the first thread had been created (which was the condition for checking p_ktr in proc_dtor()) but before p_ktr had been initialized. * Move the p_klist initialization in fork1() past the last possible failure point so we don't have to free it on failure. We didn't, which meant we were leaking a knlist every time we failed to fork due to hitting the resource limit. PR: 291470 MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54215 (cherry picked from commit 026d962ef14dafe19fa73361bea6dcc95f141dfa) sys/kern/kern_fork.c | 4 ++-- sys/kern/kern_proc.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=307cbd494b593dd3fa6828d2cceb5dc2fc06a517 commit 307cbd494b593dd3fa6828d2cceb5dc2fc06a517 Author: Dag-Erling Smørgrav <des@FreeBSD.org> AuthorDate: 2025-12-14 13:16:22 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2025-12-19 18:07:05 +0000 proc: Fix proc_init / proc_dtor ordering issues * Move the initialization of p_ktr into proc_init() and make the check in proc_dtor() unconditional. Prior to this, it was possible to fail and invoke proc_dtor() after the first thread had been created (which was the condition for checking p_ktr in proc_dtor()) but before p_ktr had been initialized. * Move the p_klist initialization in fork1() past the last possible failure point so we don't have to free it on failure. We didn't, which meant we were leaking a knlist every time we failed to fork due to hitting the resource limit. PR: 291470 MFC after: 1 week Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D54215 (cherry picked from commit 026d962ef14dafe19fa73361bea6dcc95f141dfa) sys/kern/kern_fork.c | 4 ++-- sys/kern/kern_proc.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-)