From owner-freebsd-current@FreeBSD.ORG Sat Jan 24 23:36:28 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 09055106564A; Sat, 24 Jan 2009 23:36:28 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id BF1DE8FC1A; Sat, 24 Jan 2009 23:36:27 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so5417674rvf.43 for ; Sat, 24 Jan 2009 15:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MAyZg6uZXFZzdlMZ31MTlxwaoisOxsO2xoqlapNZD/Y=; b=ekGYLA6R3HKDXjSPbCZV3ZPaH0HSTFcw3ucrl/NMRqykbgpQxhkweUGpOeLlQ8zSWp htfR12RomPUrRTqB5a/weB/FOhkWG1udjeUsnDSTdSdCjGAvLqCz3rxmkVGv/LiZ2Px5 37dk0nDjpH9O/5gpbqFegeJu0DuTLEgycGxwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pTtv420a7BAnB30zo9XUiDL+Yv9Qi11LhALMIrE8nyKSFAvAutMy1XBAAt5dwn1rVx zJyexipbnf9IEes9CfnyjWAsLrCFxWC4Kkn1rh6DCeW4o9IAqIeS4CjqJfsTjWwJfcid 60spTKcQNVJ0COJyh7fi8E741qQET0NgvrJ6w= MIME-Version: 1.0 Received: by 10.141.132.1 with SMTP id j1mr5911413rvn.282.1232840187592; Sat, 24 Jan 2009 15:36:27 -0800 (PST) In-Reply-To: <497BA473.6060007@elischer.org> References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <200901241055.20054.hselasky@c2i.net> <497BA473.6060007@elischer.org> Date: Sat, 24 Jan 2009 15:36:27 -0800 Message-ID: From: Maksim Yevmenkin To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein , Hans Petter Selasky 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 23:36:28 -0000 On Sat, Jan 24, 2009 at 3:29 PM, Julian Elischer wrote: > Maksim Yevmenkin wrote: >> >> On Sat, Jan 24, 2009 at 1:55 AM, Hans Petter Selasky >> wrote: >>> >>> 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? >> >> i already told you that netgraph is essentially single-threaded. for >> all intents and purposes think that only _ONE_ thread services _ALL_ >> netgraph nodes. if something can not be done immediately, netgraph >> queues it and returns back to it later. _ANY_ delay/sleep would stall >> _ENTIRE_ netgraph. think poll/select/callback driven programming >> model. > > it depends on the delay. > if it's going to be 200usecs.. ok (with a grumble) > if it's going to be 5mSec it is NOT ok.. > > netgraph itself does nothing that would block > (except one mutex that is guaranteed to be really quick > and is probably always satisfied in the 'spin' stage.) > we have thought about having multipel netgraph threads. > (and there is a patch to do this.. I don';t think it has been > added yet). so you are both right.. > a node should avoid doing a mutex if there is any chance that that > mutex may end up taking any real time to satisfy, due to mutex chaining > etc.) I almos think there should be a mutex type > that is called 'leaf' mutex. no other mutex may be taken > while it is held.. > In other words, you can use a mutex in Netgraph IFF you can guarantee > that all potential holders of the mutex will never acquire > any other locks or do anything that may take real time. > it's probably ok to take a lock to protect updating a statistics block > if you know that the only other holders will be the same code you are > writing, in another thread, and that that code will never need to do > anything except update the memory. > > So the question becomes. If HPS uses a mutex, what are the other users of > the mutex doing? my concern was primarily over USB_BUS_LOCK() that usb2 code uses internally. since the same bus can be shared between multiple devices, i assumed there would cases when "bad" device could potentially do things that would take some time while holding USB_BUS_LOCK(). in any case, scheduling task seemed like a right/safe thing to do. this way netgraph is protected from any delays. it also makes it less defendant on usb2 internals (i.e. we no longer need to make any assumptions about locks usb2 uses internally). thanks, max