From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:21:48 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 930E616A4CE; Mon, 30 Aug 2004 18:21:48 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AE6343D49; Mon, 30 Aug 2004 18:21:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 07D2D7A3F9; Mon, 30 Aug 2004 11:21:48 -0700 (PDT) Message-ID: <4133703B.4050601@elischer.org> Date: Mon, 30 Aug 2004 11:21:47 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20040830095729.GD30701@cell.sick.ru> <20040830144041.GA33772@cell.sick.ru> In-Reply-To: <20040830144041.GA33772@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: "Bjoern A. Zeeb" cc: Robert Watson 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 18:21:48 -0000 One option is to remove the functionality of making netgraph load kernel modules.. I think this is outside the scope of netgraph really.... Gleb Smirnoff wrote: >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. > > >