sysctl question

Roman Divacky rdivacky at freebsd.org
Wed Jan 28 14:43:47 PST 2009


On Wed, Jan 28, 2009 at 05:41:24PM -0500, John Baldwin wrote:
> On Wednesday 28 January 2009 5:04:54 pm Roman Divacky wrote:
> > On Wed, Jan 28, 2009 at 03:21:17PM -0500, John Baldwin wrote:
> > > On Wednesday 28 January 2009 2:33:18 pm Roman Divacky wrote:
> > > > hi
> > > > 
> > > > we dont need Giant to be held for sysctl_ctx_init/SYSCTL_ADD_*, right?
> > > 
> > > Ugh, it looks like the sysctl tree locking is woefully inadequate, so we 
> > > aren't quite ready for this yet.
> > 
> > what do you mean? should all sysctl_ctx_init/SYSCTL_ADD_* consumers lock
> > Giant? I didnt not find a single one (except the scsi stuff) that locks
> > it...
> > 
> > can you explain? thnx
> 
> The supposed sysctl lock in kern_sysctl.c is actually worthless.  None of the 
> routines that actually manipulate the sysctl tree to add and remove nodes use 
> it.  Only sysctl itself uses it.  It replaces an old 'memlock' hand-rolled 
> lock from 4.xBSD (in 1.1 of kern_sysctl.c) that I think has to do with 
> limiting the amount of wired memory, as it looks like sysctl used to always 
> wire the userland buffers.  I've just submitted some changes to p4 to make 
> the sysctl lock actually protect the sysctl tree that I will test soon.  Once 
> that stuff is done then Giant can be removed here and other places.

cool! I found no other places where Giant is used for locking sysctl but
please commit at least the patch I posted

thnx!

roman


More information about the freebsd-current mailing list