From owner-freebsd-current@FreeBSD.ORG Wed May 31 22:01:30 2006 Return-Path: X-Original-To: freebsd-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 072D116B213; Wed, 31 May 2006 22:01:25 +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 B0A4D43D64; Wed, 31 May 2006 22:01:22 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [131.106.61.215] (72-255-64-171.client.stsn.net [72.255.64.171]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k4VM1BQL072517; Wed, 31 May 2006 18:01:21 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 31 May 2006 17:54:19 -0400 User-Agent: KMail/1.9.1 References: <200605241749.02885.jhb@freebsd.org> <44786C48.7030109@FreeBSD.org> <200605301856.10637.jhb@freebsd.org> In-Reply-To: <200605301856.10637.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605311754.19724.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1504/Wed May 31 15:59:14 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: "Christian S.J. Peron" 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: Wed, 31 May 2006 22:01:34 -0000 On Tuesday 30 May 2006 18:56, John Baldwin wrote: > 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. Looks like we don't. :( We have a lock, but it's useless. I would hold off on testing this patch too much as I've subsequently tore it up a bunch and need to test it locally before posting an updated patch. -- John Baldwin