From: Theo de Raadt <deraadt@cvs.openbsd.org>
Subject: Re: ip sysctl atomic
To: alexander.bluhm@gmx.net, claudio@openbsd.org
Cc: mark.kettenis@xs4all.nl, tech@openbsd.org
Date: Fri, 17 May 2024 13:33:14 -0600

I think this is going off the rails.

I think some fictional "everyone must see the same value" is being
pushed here.

Can someone please provide an actual real example where this matters?

I asked before, let me ask again.  The man page says:

     Unless explicitly noted below, sysctl() returns a consistent snapshot of
     the data requested.  Consistency is obtained by locking the destination
     buffer into memory so that the data may be copied out without blocking.
     Calls to sysctl() are serialized to avoid deadlock.

I think the last sentence is incompatible with MP, and we should remove it.
Or add a 100 new biglocks, right?

Next sentence

     Consistency is obtained by locking the destination
     buffer into memory so that the data may be copied out without blocking.

That has always been untrue.  vslock is an incredibly huge block.

So really it comes down to:

     Unless explicitly noted below, sysctl() returns a consistent snapshot of
     the data requested.

bluhm is trying to fix requests of one int, or one long.

Consistant with respect to what??

The codepaths he's changing don't sleep.


Can someone PLEASE tell me of an int/long sysctl value that will be
read by multiple threads, *while* another thread is changing it (and I mean
one change) -- and where it is OBSERVABLE in the multiple readers that
something wasn't consistant?

Some will return a value *before* the write was started (OR after it was
started but did not finish yet), and others will return a value *after*
the write was started and finished.

What's the problem?

Please demonstrate a specific sysctl request where this is a real issue,
and if it is, let's go the other way and just reimpose the damn biglock
and tell people OpenBSD is always going to be slow.