From owner-freebsd-current@FreeBSD.ORG Tue May 30 22:56:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A6E416B3B9; Tue, 30 May 2006 22:56:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8105943D53; Tue, 30 May 2006 22:56:46 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [131.106.61.215] (72-255-64-170.client.stsn.net [72.255.64.170]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k4UMuicV062557; Tue, 30 May 2006 18:56:45 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Christian S.J. Peron" Date: Tue, 30 May 2006 18:56:10 -0400 User-Agent: KMail/1.9.1 References: <200605241749.02885.jhb@freebsd.org> <44786C48.7030109@FreeBSD.org> In-Reply-To: <44786C48.7030109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605301856.10637.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1500/Tue May 30 16:47:36 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: current@freebsd.org Subject: Re: [PATCH] Fixup locking for kernel-linker, needs ndis testing(!) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2006 22:56:52 -0000 On Saturday 27 May 2006 11:12, Christian S.J. Peron wrote: > > Currently, we are using Giant to serialize access into the sysctl tree. > This means that if the kernel linker is not picking up Giant, there > could be a race between when the kernel modules load/unload sysctls, and > somebody reading the sysctl tree. > > I am not sure what the best thing to do here is yet. I've looked at the > locking for sysctl tree, and locking these entry points can be sticky > due to the recursive nature of the code. I thought we had a big sx lock to protect the actual sysctl tree itself. -- John Baldwin