NetBSD Problem Report #60568
From woods@mail.weird.com Mon Aug 10 00:45:06 2026
Return-Path: <woods@mail.weird.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.netbsd.org", Issuer "YR2" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 43B5B1A9246
for <gnats-bugs@gnats.NetBSD.org>; Mon, 10 Aug 2026 00:45:06 +0000 (UTC)
Message-Id: <m1wtE2a-00MnpRC@more.local>
Date: Sun, 9 Aug 2026 17:38:56 -0700 (PDT)
From: "Greg A. Woods" <woods@planix.ca>
Sender: "Greg A. Woods" <woods@mail.weird.com>
Reply-To: "Greg A. Woods" <woods@planix.ca>
To: gnats-bugs@NetBSD.org
Subject: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
X-Send-Pr-Version: 3.95
X-From4GNATS: "Greg A. Woods via gnats" <gnats-admin@NetBSD.org>
>Number: 60568
>Category: kern
>Synopsis: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: needs-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Aug 10 00:50:00 +0000 2026
>Closed-Date:
>Last-Modified: Thu Sep 24 17:20:04 +0000 2026
>Originator: Greg A. Woods
>Release: NetBSD 11.99.7
>Organization:
Planix, Inc.; Kelowna, BC; Canada
>Environment:
System: NetBSD nbday.local 11.99.7 NetBSD 11.99.7 (XEN3_DOMU) #0: Wed Aug 5 09:51:05 UTC 2026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/xen/compile/XEN3_DOMU amd64
Architecture: x86_64
Machine: amd64
>Description:
[ 6123.1695877] Mutex error: mutex_vector_enter,551: locking against myself
[ 6123.1695877] lock address : ffff8c800d63e280
[ 6123.1695877] current cpu : 0
[ 6123.1695877] current lwp : 0xffff8c800c922000
[ 6123.1695877] owner field : 0xffff8c800c922000 wait/spin: 0/0
[ 6123.1695877] panic: lock error: Mutex: mutex_vector_enter,551: locking against myself: lock 0xffff8c800d63e280 cpu 0 lwp 0xffff8c800c922000
[ 6123.1695877] cpu0: Begin traceback...
[ 6123.1695877] vpanic() at netbsd:vpanic+0x164
[ 6123.1695877] panic() at netbsd:panic+0x3c
[ 6123.1695877] lockdebug_abort() at netbsd:lockdebug_abort+0x10f
[ 6123.1695877] mutex_vector_enter() at netbsd:mutex_vector_enter+0x2f5
[ 6123.1695877] sigpending1() at netbsd:sigpending1+0x24
[ 6123.1695877] nfs_rcvlock() at netbsd:nfs_rcvlock+0xed
[ 6123.1695877] nfs_request() at netbsd:nfs_request+0x48e
[ 6123.1817135] nfs_access() at netbsd:nfs_access+0x30b
[ 6123.1817135] VOP_ACCESS() at netbsd:VOP_ACCESS+0x55
[ 6123.1817135] getcwd_common() at netbsd:getcwd_common+0x2bd
[ 6123.1817135] vnode_to_path() at netbsd:vnode_to_path+0xbb
[ 6123.1817135] sysctl_vmproc() at netbsd:sysctl_vmproc+0x71c
[ 6123.1817135] sysctl_dispatch() at netbsd:sysctl_dispatch+0xb3
[ 6123.1817135] sys___sysctl() at netbsd:sys___sysctl+0xca
[ 6123.1817135] syscall() at netbsd:syscall+0x98
[ 6123.1817135] --- syscall (number 202) ---
[ 6123.1817135] netbsd:syscall+0x98:
[ 6123.1817135] cpu0: End traceback...
Michael van Elst noted the following:
sysctl_vmproc
-> fill_vmentries (takes p->p_lock)
-> fill_vmentry
-> vnode_to_path
-> getwd_common
-> VOP_ACCESS
... sigpending1 (wants p->p_lock)
Calling into VFS layer while holding a process lock is not
the best idea.
Note at this point the system went into a panic loop, repeatedly
reporting:
[ 6133.4867723] cpu1[1847 getty]: kernel lock spinout
[ 6133.4867957] cpu0[16442 yajl_test]: hogging kernel lock
[ 6133.4867957] ipi_msg_cpu_handler() at netbsd:ipi_msg_cpu_handler+0x59
[ 6133.4867957] ipi_cpu_handler() at netbsd:ipi_cpu_handler+0x84
[ 6133.4867957] xen_ipi_handler() at netbsd:xen_ipi_handler+0x7c
[ 6133.4867957] evtchn_do_event() at netbsd:evtchn_do_event+0x117
[ 6133.4867957] do_hypervisor_callback() at netbsd:do_hypervisor_callback+0x16b
[ 6133.4867957] Xhandle_hypervisor_callback() at netbsd:Xhandle_hypervisor_callback+0x1a
[ 6133.4867957] --- interrupt ---
[ 6133.4867957] mutex_vector_enter() at netbsd:mutex_vector_enter+0x192
[ 6133.4867957] suspendsched() at netbsd:suspendsched+0xe2
[ 6133.4867957] cpu_reboot() at netbsd:cpu_reboot+0x154
[ 6133.4867957] kern_reboot() at netbsd:kern_reboot+0x5f
[ 6133.4867957] vpanic() at netbsd:vpanic+0x16e
[ 6133.4867957] panic() at netbsd:panic+0x3c
[ 6133.4867957] lockdebug_abort() at netbsd:lockdebug_abort+0x10f
[ 6133.4867957] mutex_vector_enter() at netbsd:mutex_vector_enter+0x2f5
[ 6133.4867957] sigpending1() at netbsd:sigpending1+0x24
[ 6133.4867957] nfs_rcvlock() at netbsd:nfs_rcvlock+0xed
[ 6133.4867957] nfs_request() at netbsd:nfs_request+0x48e
[ 6133.4867957] nfs_access() at netbsd:nfs_access+0x30b
[ 6133.4867957] VOP_ACCESS() at netbsd:VOP_ACCESS+0x55
[ 6133.4867957] getcwd_common() at netbsd:getcwd_common+0x2bd
[ 6133.4867957] vnode_to_path() at netbsd:vnode_to_path+0xbb
[ 6133.4867957] sysctl_vmproc() at netbsd:sysctl_vmproc+0x71c
[ 6133.4867957] sysctl_dispatch() at netbsd:sysctl_dispatch+0xb3
[ 6133.4867957] sys___sysctl() at netbsd:sys___sysctl+0xca
[ 6133.4867957] syscall() at netbsd:syscall+0x98
[ 6133.4867957] --- syscall (number 202) ---
[ 6133.4867957] netbsd:syscall+0x98:
>How-To-Repeat:
run a small make on an NFS-mounted partition?
(it has happened twice in a row for me)
>Fix:
>Release-Note:
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: "Greg A. Woods" <woods@planix.ca>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
Date: Mon, 10 Aug 2026 02:40:04 +0000
This is a multi-part message in MIME format.
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl
Can you please try the attached patch?
(Warning: untested on my end. But if it makes your system panic,
can't be worse than what you're already observing!)
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl
Content-Type: text/plain; charset="ISO-8859-1"; name="pr60568-sysctlvmproclock"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr60568-sysctlvmproclock.patch"
# HG changeset patch
# User Taylor R Campbell <riastradh@NetBSD.org>
# Date 1786327290 0
# Mon Aug 10 02:01:30 2026 +0000
# Branch trunk
# Node ID 627f345a67f1beb9c8d462266402bb4226768c88
# Parent b125bad3265e13dfd5a772b3676744fca85ce488
# EXP-Topic riastradh-pr60568-sysctlvmproclock
WIP: sysctl vm.proc.*: Fix locking protocol.
Take p_lock only long enough for proc_vmspace_getref, and then rely
only on a read lock on p_reflock.
New subroutine proc_find_reflocked is like proc_find_locked but also
returns with p_reflock held, taking locks in the correct order
(proc_lock -> p_reflock -> p_lock) to make this work safely. (It
could just as well return with only p_reflock held, not p_lock, but
it presumably needs p_lock for KAUTH_PROCESS_CANSEE, so why bother
unlocking and relocking in the caller immediately?)
PR kern/60568: panic locking against myself (p->p_lock) in NFS from
sysctl_vmproc
diff -r b125bad3265e -r 627f345a67f1 sys/kern/kern_proc.c
--- a/sys/kern/kern_proc.c Mon Aug 03 19:24:48 2026 +0000
+++ b/sys/kern/kern_proc.c Mon Aug 10 02:01:30 2026 +0000
@@ -1789,7 +1789,7 @@ int
proc_vmspace_getref(struct proc *p, struct vmspace **vm)
{
=20
- /* XXXCDC: how should locking work here? */
+ KASSERT(p =3D=3D curproc || mutex_owned(p->p_lock));
=20
/* curproc exception is for coredump. */
=20
@@ -2946,7 +2946,20 @@ fill_kproc2(struct proc *p, struct kinfo
}
}
=20
-
+/*
+ * proc_find_reflocked(l, &p, pid, op)
+ *
+ * Look up a process p by pid, taking l->l_proc if pid =3D=3D -1, and
+ * take the mutex p->p_lock if pid !=3D -1. Verify whether the
+ * caller is allowed to see the target process before succeeding.
+ * Return nonzero error on failure.
+ *
+ * Invariant on successful return:
+ *
+ * pid =3D=3D -1 || mutex_owned(p->p_lock)
+ *
+ * Caller is responsible for mutex_exit(p->p_lock) if pid !=3D -1.
+ */
int
proc_find_locked(struct lwp *l, struct proc **p, pid_t pid)
{
@@ -2961,7 +2974,8 @@ proc_find_locked(struct lwp *l, struct p
if (*p =3D=3D NULL) {
if (pid !=3D -1)
mutex_exit(&proc_lock);
- return SET_ERROR(ESRCH);
+ error =3D SET_ERROR(ESRCH);
+ goto out;
}
if (pid !=3D -1)
mutex_enter((*p)->p_lock);
@@ -2973,7 +2987,70 @@ proc_find_locked(struct lwp *l, struct p
if (error) {
if (pid !=3D -1)
mutex_exit((*p)->p_lock);
+ goto out;
}
+out: KASSERT(error !=3D 0 || pid !=3D -1 || mutex_owned((*p)->p_lock));
+ return error;
+}
+
+/*
+ * proc_find_reflocked(l, &p, pid, op)
+ *
+ * Look up a process p by pid, taking l->l_proc if pid =3D=3D -1, and
+ * take _both_ the mutex p->p_lock _and_ p->p_reflock as a reader
+ * or writer according to op if pid !=3D -1. Verify whether the
+ * caller is allowed to see the target process before succeeding.
+ * Return nonzero error on failure.
+ *
+ * Invariants on successful return:
+ *
+ * pid =3D=3D -1 || mutex_owned(p->p_lock)
+ * pid =3D=3D -1 || rw_lock_held(p->p_lock)
+ * pid =3D=3D -1 || op !=3D RW_READER || rw_read_held(p->p_lock)
+ * pid =3D=3D -1 || op !=3D RW_WRITER || rw_write_held(p->p_lock)
+ *
+ * Caller is responsible for mutex_exit(p->p_lock) _and_
+ * rw_exit(&p->p_reflock) if pid !=3D -1.
+ */
+int
+proc_find_reflocked(struct lwp *l, struct proc **p, pid_t pid, krw_t op)
+{
+ int error;
+
+ mutex_enter(&proc_lock);
+ if (pid =3D=3D -1)
+ *p =3D l->l_proc;
+ else
+ *p =3D proc_find(pid);
+
+ if (*p =3D=3D NULL) {
+ if (pid !=3D -1)
+ mutex_exit(&proc_lock);
+ error =3D SET_ERROR(ESRCH);
+ goto out;
+ }
+ if (pid !=3D -1) {
+ rw_enter(&(*p)->p_reflock, op);
+ mutex_enter((*p)->p_lock);
+ }
+ mutex_exit(&proc_lock);
+
+ error =3D kauth_authorize_process(l->l_cred,
+ KAUTH_PROCESS_CANSEE, *p,
+ KAUTH_ARG(KAUTH_REQ_PROCESS_CANSEE_ENTRY), NULL, NULL);
+ if (error) {
+ if (pid !=3D -1) {
+ mutex_exit((*p)->p_lock);
+ rw_exit(&(*p)->p_reflock);
+ }
+ goto out;
+ }
+out: KASSERT(error !=3D 0 || pid =3D=3D -1 || mutex_owned((*p)->p_lock));
+ KASSERT(error !=3D 0 || pid =3D=3D -1 || rw_lock_held(&(*p)->p_reflock));
+ KASSERT(error !=3D 0 || pid =3D=3D -1 || op !=3D RW_READER ||
+ rw_read_held(&(*p)->p_reflock));
+ KASSERT(error !=3D 0 || pid =3D=3D -1 || op !=3D RW_WRITER ||
+ rw_write_held(&(*p)->p_reflock));
return error;
}
=20
diff -r b125bad3265e -r 627f345a67f1 sys/sys/proc.h
--- a/sys/sys/proc.h Mon Aug 03 19:24:48 2026 +0000
+++ b/sys/sys/proc.h Mon Aug 10 02:01:30 2026 +0000
@@ -496,6 +496,8 @@ extern struct proc *initproc; /* Process
extern const struct proclist_desc proclists[];
=20
int proc_find_locked(struct lwp *, struct proc **, pid_t);
+int proc_find_reflocked(struct lwp *, struct proc **, pid_t,
+ krw_t);
proc_t * proc_find_raw(pid_t);
proc_t * proc_find(pid_t); /* Find process by ID */
proc_t * proc_find_lwpid(pid_t); /* Find process by LWP ID */
diff -r b125bad3265e -r 627f345a67f1 sys/uvm/uvm_map.c
--- a/sys/uvm/uvm_map.c Mon Aug 03 19:24:48 2026 +0000
+++ b/sys/uvm/uvm_map.c Mon Aug 10 02:01:30 2026 +0000
@@ -5377,6 +5377,7 @@ fill_vmentries(struct lwp *l, pid_t pid,
struct vm_map_entry *entry;
char *dp;
size_t count, vmesize;
+ bool locked =3D false;
=20
if (elem_size =3D=3D 0 || elem_size > 2 * sizeof(*vme))
return EINVAL;
@@ -5391,15 +5392,42 @@ fill_vmentries(struct lwp *l, pid_t pid,
} else
vmesize =3D 0;
=20
- if ((error =3D proc_find_locked(l, &p, pid)) !=3D 0)
+ /*
+ * Look up the pid and:
+ *
+ * 1. take p->p_lock so we can proc_vmspace_getref,
+ *
+ * 2. take a read lock on p->p_reflock so the process cannot
+ * exit while we're doing things that can't hold p->p_lock.
+ */
+ if ((error =3D proc_find_reflocked(l, &p, pid, RW_READER)) !=3D 0)
return error;
+ KASSERT(pid =3D=3D -1 || mutex_owned(p->p_lock));
+ KASSERT(pid =3D=3D -1 || rw_read_held(&p->p_reflock));
+ locked =3D true;
=20
vme =3D NULL;
count =3D 0;
=20
+ /*
+ * Get a reference to the vmspace while we still hold
+ * p->p_lock. Then release p->p_lock so we can safely allocate
+ * memory, do vnode_to_path, &c., without deadlocking against
+ * the page daemon or proc lookup shenanigans (e.g., nfs intr
+ * signal catching) in vnode_to_path.
+ */
if ((error =3D proc_vmspace_getref(p, &vm)) !=3D 0)
goto out;
-
+ if (pid !=3D -1) {
+ mutex_exit(p->p_lock);
+ locked =3D false;
+ }
+
+ /*
+ * Take a read lock on the VM map to iterate over it.
+ *
+ * XXX Should we kmem_alloc before locking the VM map?
+ */
map =3D &vm->vm_map;
vm_map_lock_read(map);
=20
@@ -5416,12 +5444,16 @@ fill_vmentries(struct lwp *l, pid_t pid,
}
count++;
}
+
vm_map_unlock_read(map);
uvmspace_free(vm);
=20
out:
- if (pid !=3D -1)
- mutex_exit(p->p_lock);
+ if (pid !=3D -1) {
+ if (locked)
+ mutex_exit(p->p_lock);
+ rw_exit(&p->p_reflock);
+ }
if (error =3D=3D 0) {
const u_int esize =3D uimin(sizeof(*vme), elem_size);
dp =3D oldp;
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl--
From: "Greg A. Woods" <woods@planix.ca>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
Date: Mon, 10 Aug 2026 14:59:19 -0700
--pgp-sign-Multipart_Mon_Aug_10_14:59:10_2026-1
Content-Type: text/plain; charset=US-ASCII
At Mon, 10 Aug 2026 02:40:04 +0000, Taylor R Campbell <riastradh@NetBSD.org> wrote:
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
>
> [1 <text/plain (7bit)>]
> Can you please try the attached patch?
New and different panic:
[ 256.3450500] panic: kernel diagnostic assertion "error != 0 || pid != -1 || mutex_owned((*p)->p_lock)" failed: file "/Volumes/work/woods/g-NetBSD-src/sys/kern/kern_proc.c", line 2992
[ 256.3450500] cpu1: Begin traceback...
[ 256.3450500] vpanic() at netbsd:vpanic+0x164
[ 256.3450500] kern_assert() at netbsd:kern_assert+0x4b
[ 256.3450500] proc_find_locked() at netbsd:proc_find_locked+0x141
[ 256.3450500] sysctl_kern_proc_args() at netbsd:sysctl_kern_proc_args+0x2ab
[ 256.3450500] sysctl_dispatch() at netbsd:sysctl_dispatch+0xb3
[ 256.3450500] sys___sysctl() at netbsd:sys___sysctl+0xca
[ 256.3450500] syscall() at netbsd:syscall+0x98
[ 256.3450500] --- syscall (number 202) ---
[ 256.3450500] netbsd:syscall+0x98:
[ 256.3450500] cpu1: End traceback...
That's the final KASSERT() at the end of proc_find_locked()
But this time it did reboot cleanly at least!
--
Greg A. Woods <gwoods@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
--pgp-sign-Multipart_Mon_Aug_10_14:59:10_2026-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCanpJsQAKCRBmfXG3eL/0
f5YDAJ92HM7X9YKLPzPSHIEsmKA3DN3UowCg0r0pHMnHFmmlXF31ab2Pog91pZk=
=yzPs
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Mon_Aug_10_14:59:10_2026-1--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: "Greg A. Woods" <woods@planix.ca>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
Date: Tue, 11 Aug 2026 02:07:47 +0000
This is a multi-part message in MIME format.
--=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz
Content-Transfer-Encoding: quoted-printable
> Date: Mon, 10 Aug 2026 14:59:19 -0700
> From: "Greg A. Woods" <woods@planix.ca>
>=20
> At Mon, 10 Aug 2026 02:40:04 +0000, Taylor R Campbell <riastradh@NetBSD.o=
rg> wrote:
> > Can you please try the attached patch?
>=20
> New and different panic:
>=20
> [ 256.3450500] panic: kernel diagnostic assertion "error !=3D 0 || pid !=
=3D -1 || mutex_owned((*p)->p_lock)" failed: file "/Volumes/work/woods/g-Ne=
tBSD-src/sys/kern/kern_proc.c", line 2992
Sorry about that -- typo on my part (`pid !=3D -1' should've been `pid
=3D=3D -1' in that assertion), along with some other issues I saw on
review. Try the attached one instead?
It's a bit tricky to provoke the path you hit originally: I think the
vnode for a parent directory of cwd has to be recycled, causing the
nfs client to wait for network traffic to look it up again.
I'm curious to know what you were doing that led to it? Debuggers
like gdb are likely to use the affected sysctl but I'm not sure what
else.
--=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz
Content-Type: text/plain; charset="ISO-8859-1"; name="pr60568-sysctlvmproclock-v2"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr60568-sysctlvmproclock-v2.patch"
# HG changeset patch
# User Taylor R Campbell <riastradh@NetBSD.org>
# Date 1786327290 0
# Mon Aug 10 02:01:30 2026 +0000
# Branch trunk
# Node ID 2ec7a3d2a384a345cd63e0fe8fc73fdcdd274188
# Parent b125bad3265e13dfd5a772b3676744fca85ce488
# EXP-Topic riastradh-pr60568-sysctlvmproclock
WIP: sysctl vm.proc.*: Fix locking protocol.
1. proc_vmspace_getref: Take p->p_lock for access to p_sflag.
2. New subroutine proc_find_reflocked is like proc_find_locked but
returns with p_reflock held rather than p_lock.
3. Change fill_vmentries to use proc_find_reflocked instead of
proc_find_locked so we don't hold p->p_lock across kmem_alloc
(potentially deadlocking the page daemon) or vnode_to_path
(potentially tripping locking-against-self when nfs with option
`intr' checks for signal delivery).
PR kern/60568: panic locking against myself (p->p_lock) in NFS from
sysctl_vmproc
diff -r b125bad3265e -r 2ec7a3d2a384 sys/kern/kern_proc.c
--- a/sys/kern/kern_proc.c Mon Aug 03 19:24:48 2026 +0000
+++ b/sys/kern/kern_proc.c Mon Aug 10 02:01:30 2026 +0000
@@ -1785,23 +1785,44 @@ proclist_foreach_call(struct proclist *l
return ret;
}
=20
+/*
+ * proc_vmspace_getref(p, &vm)
+ *
+ * If p is not currently exiting, acquire a reference to its
+ * vmspace. Return 0, set vm, and increment its reference count
+ * on success. Return nonzero error code without on failure.
+ *
+ * Caller MUST NOT hold p->p_lock. Caller MAY hold p->p_reflock
+ * and/or proc_lock.
+ *
+ * On success, caller MUST call vmspace_free(vm) when done.
+ */
int
proc_vmspace_getref(struct proc *p, struct vmspace **vm)
{
-
- /* XXXCDC: how should locking work here? */
+ int error;
=20
/* curproc exception is for coredump. */
-
- if ((p !=3D curproc && (p->p_sflag & PS_WEXIT) !=3D 0) ||
- (p->p_vmspace->vm_refcnt < 1)) {
- return SET_ERROR(EFAULT);
+ if (p !=3D curproc) {
+ mutex_enter(p->p_lock);
+ if (p->p_sflag & PS_WEXIT) {
+ error =3D SET_ERROR(EFAULT);
+ goto out;
+ }
+ }
+
+ if (p->p_vmspace->vm_refcnt < 1) {
+ error =3D SET_ERROR(EFAULT);
+ goto out;
}
=20
uvmspace_addref(p->p_vmspace);
*vm =3D p->p_vmspace;
-
- return 0;
+ error =3D 0;
+
+out: if (p !=3D curproc)
+ mutex_exit(p->p_lock);
+ return error;
}
=20
/*
@@ -2946,7 +2967,20 @@ fill_kproc2(struct proc *p, struct kinfo
}
}
=20
-
+/*
+ * proc_find_locked(l, &p, pid, op)
+ *
+ * Look up a process p by pid, taking l->l_proc if pid =3D=3D -1, and
+ * take the mutex p->p_lock if pid !=3D -1. Verify whether the
+ * caller is allowed to see the target process before succeeding.
+ * Return nonzero error on failure.
+ *
+ * Invariant on successful return:
+ *
+ * pid =3D=3D -1 || mutex_owned(p->p_lock)
+ *
+ * Caller is responsible for mutex_exit(p->p_lock) if pid !=3D -1.
+ */
int
proc_find_locked(struct lwp *l, struct proc **p, pid_t pid)
{
@@ -2959,9 +2993,9 @@ proc_find_locked(struct lwp *l, struct p
*p =3D proc_find(pid);
=20
if (*p =3D=3D NULL) {
- if (pid !=3D -1)
- mutex_exit(&proc_lock);
- return SET_ERROR(ESRCH);
+ mutex_exit(&proc_lock);
+ error =3D SET_ERROR(ESRCH);
+ goto out;
}
if (pid !=3D -1)
mutex_enter((*p)->p_lock);
@@ -2973,7 +3007,64 @@ proc_find_locked(struct lwp *l, struct p
if (error) {
if (pid !=3D -1)
mutex_exit((*p)->p_lock);
+ goto out;
}
+out: KASSERT(error !=3D 0 || pid =3D=3D -1 || mutex_owned((*p)->p_lock));
+ return error;
+}
+
+/*
+ * proc_find_reflocked(l, &p, pid, op)
+ *
+ * Look up a process p by pid, taking l->l_proc iff pid =3D=3D -1, and
+ * take p->p_reflock as a reader or writer according to op iff pid
+ * !=3D -1. Verify whether the caller is allowed to see the target
+ * process before succeeding. Return nonzero error on failure.
+ *
+ * Invariants on successful return:
+ *
+ * pid =3D=3D -1 || rw_lock_held(p->p_lock)
+ * pid =3D=3D -1 || op !=3D RW_READER || rw_read_held(p->p_lock)
+ * pid =3D=3D -1 || op !=3D RW_WRITER || rw_write_held(p->p_lock)
+ *
+ * Caller is responsible for rw_exit(&p->p_reflock) iff pid !=3D -1.
+ */
+int
+proc_find_reflocked(struct lwp *l, struct proc **p, pid_t pid, krw_t op)
+{
+ int error;
+
+ mutex_enter(&proc_lock);
+ if (pid =3D=3D -1)
+ *p =3D l->l_proc;
+ else
+ *p =3D proc_find(pid);
+
+ if (*p =3D=3D NULL) {
+ mutex_exit(&proc_lock);
+ error =3D SET_ERROR(ESRCH);
+ goto out;
+ }
+ if (pid !=3D -1) {
+ rw_enter(&(*p)->p_reflock, op);
+ mutex_enter((*p)->p_lock);
+ }
+ mutex_exit(&proc_lock);
+
+ error =3D kauth_authorize_process(l->l_cred,
+ KAUTH_PROCESS_CANSEE, *p,
+ KAUTH_ARG(KAUTH_REQ_PROCESS_CANSEE_ENTRY), NULL, NULL);
+
+out: if (pid !=3D -1 && *p !=3D NULL) {
+ mutex_exit((*p)->p_lock);
+ if (error)
+ rw_exit(&(*p)->p_reflock);
+ }
+ KASSERT(error !=3D 0 || pid =3D=3D -1 || rw_lock_held(&(*p)->p_reflock));
+ KASSERT(error !=3D 0 || pid =3D=3D -1 || op !=3D RW_READER ||
+ rw_read_held(&(*p)->p_reflock));
+ KASSERT(error !=3D 0 || pid =3D=3D -1 || op !=3D RW_WRITER ||
+ rw_write_held(&(*p)->p_reflock));
return error;
}
=20
diff -r b125bad3265e -r 2ec7a3d2a384 sys/sys/proc.h
--- a/sys/sys/proc.h Mon Aug 03 19:24:48 2026 +0000
+++ b/sys/sys/proc.h Mon Aug 10 02:01:30 2026 +0000
@@ -496,6 +496,8 @@ extern struct proc *initproc; /* Process
extern const struct proclist_desc proclists[];
=20
int proc_find_locked(struct lwp *, struct proc **, pid_t);
+int proc_find_reflocked(struct lwp *, struct proc **, pid_t,
+ krw_t);
proc_t * proc_find_raw(pid_t);
proc_t * proc_find(pid_t); /* Find process by ID */
proc_t * proc_find_lwpid(pid_t); /* Find process by LWP ID */
diff -r b125bad3265e -r 2ec7a3d2a384 sys/uvm/uvm_map.c
--- a/sys/uvm/uvm_map.c Mon Aug 03 19:24:48 2026 +0000
+++ b/sys/uvm/uvm_map.c Mon Aug 10 02:01:30 2026 +0000
@@ -5391,15 +5391,29 @@ fill_vmentries(struct lwp *l, pid_t pid,
} else
vmesize =3D 0;
=20
- if ((error =3D proc_find_locked(l, &p, pid)) !=3D 0)
+ /*
+ * Look up the pid and take a read lock on p->p_reflock so the
+ * process cannot exit while we're still working with it.
+ */
+ if ((error =3D proc_find_reflocked(l, &p, pid, RW_READER)) !=3D 0)
return error;
+ KASSERT(pid =3D=3D -1 || rw_read_held(&p->p_reflock));
=20
vme =3D NULL;
count =3D 0;
=20
+ /*
+ * XXX Is this still necessary, now that we hold p_reflock to
+ * prevent concurrent exit?
+ */
if ((error =3D proc_vmspace_getref(p, &vm)) !=3D 0)
goto out;
=20
+ /*
+ * Take a read lock on the VM map to iterate over it.
+ *
+ * XXX Should we kmem_alloc before locking the VM map?
+ */
map =3D &vm->vm_map;
vm_map_lock_read(map);
=20
@@ -5416,12 +5430,13 @@ fill_vmentries(struct lwp *l, pid_t pid,
}
count++;
}
+
vm_map_unlock_read(map);
uvmspace_free(vm);
=20
out:
if (pid !=3D -1)
- mutex_exit(p->p_lock);
+ rw_exit(&p->p_reflock);
if (error =3D=3D 0) {
const u_int esize =3D uimin(sizeof(*vme), elem_size);
dp =3D oldp;
--=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz--
From: "Greg A. Woods" <woods@planix.ca>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
Date: Mon, 10 Aug 2026 19:27:21 -0700
--pgp-sign-Multipart_Mon_Aug_10_19:27:09_2026-1
Content-Type: text/plain; charset=US-ASCII
At Tue, 11 Aug 2026 02:07:47 +0000, Taylor R Campbell <riastradh@NetBSD.org> wrote:
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
>
> Sorry about that -- typo on my part (`pid != -1' should've been `pid
> == -1' in that assertion), along with some other issues I saw on
> review. Try the attached one instead?
No worries! It'll have to wait until tomorrow though.
> It's a bit tricky to provoke the path you hit originally: I think the
> vnode for a parent directory of cwd has to be recycled, causing the
> nfs client to wait for network traffic to look it up again.
>
> I'm curious to know what you were doing that led to it? Debuggers
> like gdb are likely to use the affected sysctl but I'm not sure what
> else.
I'm basically just running "make regress" in my yajl project.
I think it failed during the initial build a few times, i.e. just
running the compiler, but the latest crash was during the run of the
regression tests.
I'm pretty sure the latest run was with "-fsanitizer=address" as well.
I was initially just trying to figure out if UBSAN was finally working
in -current, but so far as I can tell it is not, though ASAN seems to
work (and did even back with gcc-9.3.0). UBSAN compiled and linked
binaries won't even print out their help message. So far I've only had
UBSAN work with Clang on FreeBSD and macOS (I haven't tried any linux in
over a year).
--
Greg A. Woods <gwoods@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
--pgp-sign-Multipart_Mon_Aug_10_19:27:09_2026-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCanqIgQAKCRBmfXG3eL/0
f1mCAJ0U/lIN3V14z6AgE7XqYlqh9t5VpACfVcwE9IdIFSgq5ogNrRaWPM5FO/o=
=C0IM
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Mon_Aug_10_19:27:09_2026-1--
From: "Greg A. Woods" <woods@planix.ca>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: NetBSD GNATS <gnats-bugs@NetBSD.org>
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
Date: Tue, 11 Aug 2026 14:14:12 -0700
--pgp-sign-Multipart_Tue_Aug_11_14:13:52_2026-1
Content-Type: text/plain; charset=US-ASCII
At Tue, 11 Aug 2026 02:07:47 +0000, Taylor R Campbell <riastradh@NetBSD.org> wrote:
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
>
> Sorry about that -- typo on my part (`pid != -1' should've been `pid
> == -1' in that assertion), along with some other issues I saw on
> review. Try the attached one instead?
Success it seems -- I've been running "make regress" in a loop with your
second patch applied and it's happily spinning away through multiple
runs (whereas before it could never make it through a whole run).
--
Greg A. Woods <gwoods@acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
--pgp-sign-Multipart_Tue_Aug_11_14:13:52_2026-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCanuQlgAKCRBmfXG3eL/0
fyGrAKDyhl7QR369kUcJ8YnvLhYC7u3CaACguGPqjIRnUjnN1DMziJF3njEkT/8=
=l8Os
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Tue_Aug_11_14:13:52_2026-1--
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60568 CVS commit: src/sys
Date: Fri, 14 Aug 2026 03:01:23 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 14 03:01:23 UTC 2026
Modified Files:
src/sys/kern: kern_proc.c
src/sys/sys: proc.h
Log Message:
kern: New function proc_find_reflocked.
This is like proc_find_locked but returns with p_reflock held rather
than p_lock. Will be used to replace proc_find_locked in order to
fix:
PR kern/60568: panic locking against myself (p->p_lock) in NFS from
sysctl_vmproc
No modules currently use proc_find_locked or proc_find_reflocked, so
there should be no module ABI compatibility issues here.
To generate a diff of this commit:
cvs rdiff -u -r1.283 -r1.284 src/sys/kern/kern_proc.c
cvs rdiff -u -r1.373 -r1.374 src/sys/sys/proc.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60568 CVS commit: src/sys/uvm
Date: Fri, 14 Aug 2026 03:02:41 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 14 03:02:41 UTC 2026
Modified Files:
src/sys/uvm: uvm_map.c
Log Message:
sysctl vm.proc.*: Use p_reflock, not p_lock.
- Avoid holding p_lock across copyout; this risks deadlock or panic
if memory is exhausted and the uvm fault handler during copyout
tries to deliver SIGKILL, which requires p_lock.
- Avoid holding p_lock across vnode_to_path: this risks deadlock or
panic if the file system, such as nfs, tries to check for pending
signals, which requires p_lock.
PR kern/60568: panic locking against myself (p->p_lock) in NFS from
sysctl_vmproc
To generate a diff of this commit:
cvs rdiff -u -r1.431 -r1.432 src/sys/uvm/uvm_map.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60568 CVS commit: src/sys/kern
Date: Fri, 14 Aug 2026 03:03:41 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 14 03:03:41 UTC 2026
Modified Files:
src/sys/kern: kern_proc.c
Log Message:
sysctl kern.proc_args.*.cwd/pathname: Use p_reflock, not p_lock.
- Avoid holding p_lock across copyout; this risks deadlock or panic
if memory is exhausted and the uvm fault handler during copyout
tries to deliver SIGKILL, which requires p_lock.
- Avoid holding p_lock across vnode_to_path: this risks deadlock or
panic if the file system, such as nfs, tries to check for pending
signals, which requires p_lock.
PR kern/60568: panic locking against myself (p->p_lock) in NFS from
sysctl_vmproc
To generate a diff of this commit:
cvs rdiff -u -r1.284 -r1.285 src/sys/kern/kern_proc.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60568 CVS commit: src/sys/kern
Date: Fri, 14 Aug 2026 03:04:22 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 14 03:04:22 UTC 2026
Modified Files:
src/sys/kern: kern_proc.c
Log Message:
proc_vmspace_getref: Take p->p_lock around p->p_sflag access.
Prompted by reviewing the locking rules in;
PR kern/60568: panic locking against myself (p->p_lock) in NFS from
sysctl_vmproc
To generate a diff of this commit:
cvs rdiff -u -r1.285 -r1.286 src/sys/kern/kern_proc.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 14 Aug 2026 20:48:19 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-11, pullup-10, pullup-9
From: "Greg A. Woods" <woods@planix.ca>
To: NetBSD GNATS <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: kern/60568: panic locking against myself (p->p_lock) in NFS from sysctl_vmproc
Date: Thu, 24 Sep 2026 10:19:53 -0700
--pgp-sign-Multipart_Thu_Sep_24_10:19:41_2026-1
Content-Type: text/plain; charset=US-ASCII
Indeed the pullup to the release branches would be appreciated!
Looks like the lock caused it to fail to reboot too? It was hung after
the dump finished and I sent it a BREAK via conserver. After the
"reboot" the bootstrap ran (I saw the MBR boot message on the VGA
screen) but it didn't seem to respond on the serial port and I had to
power cycle it to get it to full reboot. It's a ancient Dell PE2650.
This is from a stock build of netbsd-10 from yesterday:
$ uname -a
NetBSD once 10.2_STABLE NetBSD 10.2_STABLE (GENERIC) #88: Wed Sep 23 01:21:04 PDT 2026 sysbuild@once:/home/sysbuild/i386/obj/home/sysbuild/src/sys/arch/i386/compile/GENERIC i386
[ 12701.1919017] Mutex error: mutex_vector_enter,548: locking against myself
[ 12701.2019207] lock address : c8ca35c0
[ 12701.2019207] current cpu : 1
[ 12701.2119255] current lwp : 0x00000000c8c87680
[ 12701.2119255] owner field : 0x00000000c8c87680 wait/spin: 0/0
[ 12701.2219370] panic: lock error: Mutex: mutex_vector_enter,548: locking against myself: lock 0xc8ca35c0 cpu 1 lwp 0xc8c87680
[ 12701.2319452] cpu1: Begin traceback...
[ 12701.2419550] vpanic(c12a9f60,e7cf7904,e7cf79b4,c0cd12bd,c12a9f60,c12a6680,c11a12bc,224,c12a664f,c8ca35c0) at netbsd:vpanic+0x196
[ 12701.2519695] panic(c12a9f60,c12a6680,c11a12bc,224,c12a664f,c8ca35c0,1,c8c87680,c11a12bc,61633863) at netbsd:panic+0x18
[ 12701.2719967] lockdebug_abort(c11a12bc,224,c8ca35c0,c14f2dc4,c12a664f,c8c87680,c8c87680,e7cf7a40,c0c96822,c12a664f) at netbsd:lockdebug_abort+0x11f
[ 12701.2920236] mutex_abort(c12a664f,0,c0d0d0d1,0,c683b500,0,0,c8c87680,0,0) at netbsd:mutex_abort+0x2f
[ 12701.3020374] mutex_vector_enter(c8ca35c0,c8dab2c0,0,c6610e00,e7cf7a90,c0bd2048,c8c87680,e7cf7a74,0,1000000) at netbsd:mutex_vector_enter+0x33b
[ 12701.3220626] sigpending1(c8c87680,e7cf7a74,0,1000000,c6610e04,0,0,c8c87680,c683b500,0) at netbsd:sigpending1+0x20
[ 12701.3320757] nfs_rcvlock(c6610e00,c8dab2c0,c683b500,c8dab2c0,c8c87680,0,e7cf7b4c,0,c6787700,24) at netbsd:nfs_rcvlock+0xbb
[ 12701.3420892] nfs_request(c8d2ed44,c6787700,4,c8c87680,c8a77940,e7cf7bf4,e7cf7bf8,e7cf7bec,0,c6787800) at netbsd:nfs_request+0x386
[ 12701.3621155] nfs_access(e7cf7c24,0,140,c11a4630,c8d3dc80,140,c8a77940,c8d3dc80,e7cf7d54,c0d1d803) at netbsd:nfs_access+0x1e0
[ 12701.3721281] VOP_ACCESS(c8d3dc80,140,c8a77940,c644f068,0,40,0,c0c969a9,c5ddf0ba,50) at netbsd:VOP_ACCESS+0x63
[ 12701.3921548] getcwd_common(c8e88040,c63e93c0,e7cf7d80,c644f068,ff,1,c8c87680,c644f268,c8d65300,c644f25a) at netbsd:getcwd_common+0x263
[ 12701.4021682] vnode_to_path(c644f068,200,c8ce8900,c8c87680,c8d65300,0,c8a31dfc,c644f000,c8a31df8,2dea) at netbsd:vnode_to_path+0xb5
[ 12701.4221937] sysctl_vmproc(e7cf7f04,3,bb0bd000,e7cf7ef8,0,0,e7cf7efc,c8c87680,c5e06304,f000) at netbsd:sysctl_vmproc+0x626
[ 12701.4422203] sysctl_dispatch(e7cf7efc,5,bb0bd000,e7cf7ef8,0,0,e7cf7efc,c8c87680,c5e06304,e520) at netbsd:sysctl_dispatch+0x99
[ 12701.4522338] sys___sysctl(c8c87680,e7cf7f68,e7cf7f60,c8ade600,1,ca,e7cf7f60,e7cf7f68,0,0) at netbsd:sys___sysctl+0xda
[ 12701.4722598] syscall() at netbsd:syscall+0x1d6
[ 12701.4822741] --- syscall (number 202) ---
[ 12701.4822741] bb460b87:
[ 12701.4822741] cpu1: End traceback...
[ 12701.4922887] dumping to dev 19,1 offset 525311
[ 12701.4922887] dump 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 succeeded
[halt sent]
[ 68530.7779193] fatal breakpoint trap in supervisor mode
[ 68530.7779193] trap type 1 code 0 eip 0xc0127f74 cs 0x8 eflags 0x202 cr2 0xaf3af000 ilevel 0x8 esp 0xdd5e1e8c
[ 68530.7779193] curlwp 0xc90ff780 pid 12616 lid 12616 lowest kstack 0xe7ef62c0
Stopped in pid 12616.12616 (sh) at netbsd:breakpoint+0x4: popl %ebp
db{0}> bt
breakpoint(c612926c,5,0,6ab551c7,0,c6129344,c61293cc,c61e0002,c61e1000,dd5e1ec6)
at netbsd:breakpoint+0x4
comintr(c6129200,c0cbab27,1ec,686e98,c150da98,6,1,0,c61e1000,c0105a48) at netbsd
:comintr+0x8c2
intr_kdtrace_wrapper(c62161c0,dd5e1ec4,6,c6210010,30,c62c0010,c6210010,6,1,dd5e1
f44) at netbsd:intr_kdtrace_wrapper+0x2d
Xintr_ioapic_edge7() at netbsd:Xintr_ioapic_edge7+0xc8
--- interrupt ---
_kernel_lock(1,0,dd5e1f70,c049ebfb,c14bc0c0,0,0,0,c61c1000,c010b5ec) at netbsd:_
kernel_lock+0xca
intr_biglock_wrapper(c5e18900,e7ef7f64,0,0,0,0,0,0,0,0) at netbsd:intr_biglock_w
rapper+0x17
--- switch to interrupt stack ---
Xintr_ioapic_level1() at netbsd:Xintr_ioapic_level1+0xcc
--- interrupt ---
netbsd:Xtrap0e+0x4c:
db{0}>
--
Greg A. Woods
Planix, Inc.
<woods@planix.ca> +1 250 762-7675 http://www.planix.ca/
--pgp-sign-Multipart_Thu_Sep_24_10:19:41_2026-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCarVbsAAKCRBmfXG3eL/0
f0yUAJ94/a4Ck7JEccmnKzNSEFtnroufcACfV/HS8TsBYcLiZP1lb1fFAhuhpts=
=tK3V
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Thu_Sep_24_10:19:41_2026-1--
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home