Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> The real issue with the diff is that by dropping the net lock from the
> sysctl code paths the global variables that are used to make decisions
> in the network stack can now change while running code in the network
> stack that holds the net lock.  We must guarantee consistency in those
> codepaths.  If net.inet.ip.forwarding=1 and we go down the code path
> to forward the packet and further down that code path we check
> net.inet.ip.forwaring again and the value is now 0, the code may do
> the wrong thing.

I don't see how that problem was prevented in with a big lock around
sysctl.

Imagine network code samples net.inet.ip.forwarding.

Then it creates a mbuf and queues it somewhere

Other threads do numerous sysctl, why not??

Next it is dequeued, and net.inet.ip.forwarding is inspected again?

I think what's being explained here only happens if the two inspections
of net.inet.ip.forwarding were prevented because of a quick serialization
of them, but the network code has never held itself to such a standard,
and this problem being described is *NOT* sysctl, but some weird "a huge
pile of well-known userland-coupled global variables must operate in sync
while the network code splits operations between layers".

Why are we even talking about that?

In that instance, the first net.inet.ip.forwarding=1 would queue a mbuf,
and the later one would probably result in a discard.

I don't see the big deal; the scenario seems fictious.