On Mon, Oct 21, 2024 at 01:14:50PM +0200, Mark Kettenis wrote:
> > Date: Mon, 21 Oct 2024 13:44:44 +0300
> > From: Vitaliy Makkoveev <mvs@openbsd.org>
> > 
> > timeout(9) statistics protected by `timeout_mutex', so it could be
> > easily unlocked. However, I want to introduce additional `tos_lock'
> > rwlock(9) to disallow simultaneous `timeout_mutex' acquisition from
> > timeout_sysctl() threads.
> 
> Why?  This makes no sense to me.  This is just copying 96 bytes.  I
> doubt there will be any serious contention on the timeout_mutex from
> reading the stats.
> 

I have doubts about systems with many CPUs, but can't do measurements.
However, it's easy to exclude kern_timeout.c hunk.

Index: sys/kern/kern_sysctl.c
===================================================================
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
diff -u -p -r1.448 kern_sysctl.c
--- sys/kern/kern_sysctl.c	30 Sep 2024 12:32:26 -0000	1.448
+++ sys/kern/kern_sysctl.c	21 Oct 2024 11:19:12 -0000
@@ -564,6 +564,8 @@ kern_sysctl(int *name, u_int namelen, vo
 			return (ENXIO);
 		return (sysctl_rdint(oldp, oldlenp, newp, mp->msg_bufs));
 	}
+	case KERN_TIMEOUT_STATS:
+		return (timeout_sysctl(oldp, oldlenp, newp, newlen));
 	case KERN_OSREV:
 	case KERN_MAXPROC:
 	case KERN_MAXFILES:
@@ -736,8 +738,6 @@ kern_sysctl_locked(int *name, u_int name
 	case KERN_PFSTATUS:
 		return (pf_sysctl(oldp, oldlenp, newp, newlen));
 #endif
-	case KERN_TIMEOUT_STATS:
-		return (timeout_sysctl(oldp, oldlenp, newp, newlen));
 	case KERN_UTC_OFFSET:
 		return (sysctl_utc_offset(oldp, oldlenp, newp, newlen));
 	default: