From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:40:44 2004 Return-Path: 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 A860A16A4CE; Mon, 30 Aug 2004 14:40:44 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF5D943D3F; Mon, 30 Aug 2004 14:40:43 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7UEegM6033788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 18:40:42 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7UEefoZ033787; Mon, 30 Aug 2004 18:40:41 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 30 Aug 2004 18:40:41 +0400 From: Gleb Smirnoff To: Robert Watson Message-ID: <20040830144041.GA33772@cell.sick.ru> References: <20040830095729.GD30701@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: "Bjoern A. Zeeb" cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 30 Aug 2004 14:40:44 -0000 On Mon, Aug 30, 2004 at 10:35:05AM -0400, Robert Watson wrote: R> > B> > This causes Giant to be acquired in the event we enter the linker code R> > B> > (and hence VFS code) via netgraph ngc_send(). It should be safe in this R> > B> > context as we enter protocol send routines without mutexes held (i.e., why R> > B> > we're also able to do blocking memory allocation here.) R> > B> R> > B> please commit. R> > R> > I think Giant should be acquired in linker_load_module(), and this way R> > we will prevent this panic in other codepaths. For example in R> > vfs_mount.c, when vfs will be Giant-free. Have I missed something? R> R> Well, one of the primary reasons the linker needs Giant here is its use of R> VFS. I think for now I'd like to acquire Giant in netgraph so as to R> expose the use of Giant in that piece of the network stack in the calling R> code. We might want to add GIANT_REQUIRED assertions in the linker code R> to make sure we trigger assertions even if the linker doesn't hit VFS to R> make sure potentially hitting Giant is caught. OK. Then commit it pls. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE