From owner-freebsd-arch@FreeBSD.ORG Mon Oct 11 19:30:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82EEF16A4CE; Mon, 11 Oct 2004 19:30:32 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24BEB43D2F; Mon, 11 Oct 2004 19:30:32 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9BJUODI068849; Mon, 11 Oct 2004 12:30:28 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410111930.i9BJUODI068849@gw.catspoiler.org> Date: Mon, 11 Oct 2004 12:30:24 -0700 (PDT) From: Don Lewis To: ssouhlal@FreeBSD.org In-Reply-To: <1097467017.5258.34.camel@zZzZ.segfaulted.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 19:30:32 -0000 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.