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