[RFC] sysctl locking
    Don Lewis 
    truckman at FreeBSD.org
       
    Mon Oct 11 12:30:32 PDT 2004
    
    
  
On 10 Oct, Suleiman Souhlal wrote:
> Hello,
> 
> In the past few days, I have managed to remove Giant from sysctl. The
> patch is at
> http://people.freebsd.org/~ssouhlal/testing/sysctl-locking.diff
> This is the first time I ever do something like this, so I wouldn't be
> surprised if I am doing something wrong.
> Any suggestions/comments?
> 
> green@ also pointed out that I might need to use memory barriers, or
> some other synchronization primitive, when setting oid_owner to NULL in
> sysctl_oid_disown, but I am unsure on how to do that..
> 
> Thanks in advance for your help.
There seems to be a lot of locking/unlocking overhead in the oid lookup
and oid tree manipulation code.  Doing the traversals at each level of
the tree without holding a lock for the entire time makes me nervous,
though I can't point to any specific problem.  It might be better to
just hold a single lock across then entire lookup, insertion, or
deletion operation.
What happens if:
	thread A owns an oid
	thread B, which wants to delete the oid, goes to sleep to wait
	for the oid
	thread C wants the oid and goes to sleep
	thread A releases the oid and wakes up thread B
	thread B deletes the oid
	thread C does ???
I don't think that you can arbitrarily remove
	mtx_assert(&Giant, MA_OWNED)
from the handlers.  Some of the handlers probably need Giant for correct
operation.  It's probably possible to change these into
mtx_lock()/mtx_unlock() pairs.
    
    
More information about the freebsd-arch
mailing list