From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 09:52:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 848F8106564A; Sat, 24 Jan 2009 09:52:58 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swip.net [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 8CADC8FC27; Sat, 24 Jan 2009 09:52:57 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=nTib0wbUE7AA:10 a=J2nnhgZB8JEA:10 a=w3uX68szt58dvCyVyYAA:9 a=2OVIdxriSsmP6dbp0kIA:7 a=KAdawnMWUfuzbm46TTQzYsL2H60A:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 442075885; Sat, 24 Jan 2009 10:52:55 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 24 Jan 2009 10:55:18 +0100 User-Agent: KMail/1.9.7 References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901241055.20054.hselasky@c2i.net> Cc: Alfred Perlstein , current@freebsd.org, Maksim Yevmenkin Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 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: Sat, 24 Jan 2009 09:52:59 -0000 On Saturday 24 January 2009, Maksim Yevmenkin wrote: > Hans Petter, > > i'm sorry, did i mention there is no sleeping in netgraph? :-) Can you elaborate this? Is netgraph run from fast interrupt context? So that only spin locks are possible? Or is it run from a thread? > > from what i can see you are _NOT_ using _SPIN_ mutexes (aka spin > locks). you are using regular mutexes. let me quote locking(9) man > page > > " > Mutexes > Basically (regular) mutexes will deschedule the thread if the mutex > can not be acquired. A non-spin mutex can be considered to be equivalent > to getting a write lock on an rw_lock (see below), > " > > so, if thread can not get mutex it will be descheduled. this > absolutely can not happen in netgraph! There are mutexes inside the taskqueue aswell. The problem will be the same there if you don't use a so-called fast tasqueue. > > > shutdown method is called as part of ng_rmnode_self() and drop the > reference that node was born with. the extra reference before > ng_rmnode_self() is to ensure that node pointer is still valid after > ng_rmnode_self() returns. otherwise there is a change that node > pointer becomes invalid while after ng_rmnode_self() calls shutdown > method. Ok, I need to fix that. > > first of all, i do not think crashes are caused by detach(). in fact, > detach() is clean. i've tested it and it worked for me. i tried to > start/stop device while doing flood l2ping. i also tried to yank the > device while doing flood l2ping. it works correctly. i think, the > issue is related to stalled transfers. there is still something wrong > with the code path that deals with stalled transfers. stalls do not > happen on my test box, so i can not test it. also there is NO code > duplication. asynchronous path is required to decouple netgraph from > usb2. Only if netgraph is run from fast interrupt context. > regular mutexes can sleep. we are not allowed to sleep in netgraph. > therefor we must transition out of netgraph context before calling > into any code that tries to grab regular mutex. the async design is > there not because i want to make things complicated. its there because > it is needed. I think there are two definitions of sleeping. 1) When a thread is waiting for a mutex it is not sleeping in the same way like if it was to call "tsleep()". 2) When a thread is waiting for a wakeup it is surely sleeping, which can happen inside sx_lock() and tsleep(). --HPS