Date: Sat, 24 Jan 2009 15:36:27 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-current@freebsd.org, current@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, Hans Petter Selasky <hselasky@c2i.net> Subject: Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127 Message-ID: <bb4a86c70901241536r1fe4651embae485571a84f986@mail.gmail.com> In-Reply-To: <497BA473.6060007@elischer.org> References: <20090123154336.GJ60948@e.0x20.net> <200901240952.21670.hselasky@c2i.net> <bb4a86c70901240138g6a221fd4rbab3945193e4617@mail.gmail.com> <200901241055.20054.hselasky@c2i.net> <bb4a86c70901241043i107b3199hf0532f0824cc5972@mail.gmail.com> <497BA473.6060007@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 24, 2009 at 3:29 PM, Julian Elischer <julian@elischer.org> wrote: > Maksim Yevmenkin wrote: >> >> On Sat, Jan 24, 2009 at 1:55 AM, Hans Petter Selasky <hselasky@c2i.net> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70901241536r1fe4651embae485571a84f986>