Re: which lock protects sysctl instances ?

On Fri, 22 Jul 2005, Luigi Rizzo wrote:

> is there any protection in RELENG_5 and above for multiple sysctl 
> handlers ?
>
> In other words, assume i have SYSCTL_PROC(_kern, OID_AUTO, foo, 
> CTLTYPE_STRING|CTLFLAG_RW,
>       0, 0, sysctl_foo_handler, "A", "bla bla bla");
>
> do i have to worry about multiple instances of sysctl_foo_handler() 
> running in parallel, or they run under Giant, or some other lock ?

Right now, all sysctl handlers are run with Giant.  In addition to giant, 
there are sleep locks in sysctl to protect the sysctl infrastructure.

Any further synchronization has to be done by the handler itself.  So, for 
example, you'll see that the process-related handlers all acquire the 
necessary process locks to operate successfully; likewise network 
monitoring sysctls, and so on.

Right now many sysctl handlers assume that Giant will be held on entry; 
this is an assumption that we should be reducing or gradually removing. 
As a general rule, if your sysctl handler interacts with an MPSAFE part of 
the system, it will need to acquire locks anyway, because those parts of 
the system well be running in another thread on another CPU but without 
Giant, so unimpeded.

I think we need someone to pick up sysctl again as an owner and start to 
fix this up -- it's not pressing since it's hardly a performance-critical 
path for most systems, but it's an area where cleanliness is a good thing.

Robert N M Watson