Date: Mon, 11 Oct 2004 12:30:24 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: ssouhlal@FreeBSD.org Cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] sysctl locking Message-ID: <200410111930.i9BJUODI068849@gw.catspoiler.org> In-Reply-To: <1097467017.5258.34.camel@zZzZ.segfaulted.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410111930.i9BJUODI068849>