[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