From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:37:36 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 1933116A4CE; Mon, 30 Aug 2004 14:37:36 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD4CF43D5C; Mon, 30 Aug 2004 14:37:35 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7UEZ5Sn019446; Mon, 30 Aug 2004 10:35:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7UEZ5uL019443; Mon, 30 Aug 2004 10:35:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 30 Aug 2004 10:35:05 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20040830095729.GD30701@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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:37:36 -0000 On Mon, 30 Aug 2004, Gleb Smirnoff wrote: > B> > This causes Giant to be acquired in the event we enter the linker code > B> > (and hence VFS code) via netgraph ngc_send(). It should be safe in this > B> > context as we enter protocol send routines without mutexes held (i.e., why > B> > we're also able to do blocking memory allocation here.) > B> > B> please commit. > > I think Giant should be acquired in linker_load_module(), and this way > we will prevent this panic in other codepaths. For example in > vfs_mount.c, when vfs will be Giant-free. Have I missed something? Well, one of the primary reasons the linker needs Giant here is its use of VFS. I think for now I'd like to acquire Giant in netgraph so as to expose the use of Giant in that piece of the network stack in the calling code. We might want to add GIANT_REQUIRED assertions in the linker code to make sure we trigger assertions even if the linker doesn't hit VFS to make sure potentially hitting Giant is caught. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research