Re: panic: mutex Giant not owned at /usr/src/sys/kern/tty_ttydisc.c:1127

Alfred Perlstein wrote:
> * Maksim Yevmenkin <maksim.yevmenkin_at_gmail.com> [090124 17:33] wrote:
>> On Sat, Jan 24, 2009 at 4:30 PM, Alfred Perlstein <alfred_at_freebsd.org> wrote:
>>> From a purely academic standpoint... why can't netgraph use
>>> standard mutexes?
>>>
>>> Is there a pointer you can give me?
>> well, its not that netgraph can not use mutexes at all. its just that
>> there has to be an understanding between all subsystems that interact
>> with netgraph. its just like Julian said, everybody has to play nice
>> and ensure that control is given back to netgraph as soon as possible.
>> netgraph thread can not be de-scheduled for too long because the same
>> thread services other nodes. in fact, there are other netgraph nodes
>> that use mutexes, there is no way around it. the only rule is that
>> mutexes have to be used prudently. if there is a guarantee that every
>> single code path that is called from netgraph context is "safe" (i.e.
>> any mutexes that are touched in the code path are guaranteed to not
>> cause de-scheduling of netgraph thread for any significant amount of
>> time) then everything is fine.
>>
>> in any case, i really do hope that the patch that i send to Hans
>> Petter today (you were cc'd) is something that we all can agree on.
> 
> FWIW, with the exception of Giant, all normal mutexes have this
> guarantee.  Giant actually sort of has this guarantee, however it
> may be held for long periods of _activity_.
> 
> You can't "block" with a mutex, hence you'll never be behind
> a sleeping process, only a running process or tandem of running
> processes.
> 
well there is blocking and there is blocking..

if you block on a thread that is going to switch two pointers 
atomically then that is ok as this si not going to harm throughput
of netgraph as a whole. If you block for a thread that is allocating
memory, and re-arange the routing table or something large like that,
you can really screw up netgraph's thoughput as yo are blocking
a thread that ahs to do work in other places too and because your node 
has blocked it, other nodes are getting starved.

See my mail to arch on this topic.. I'm suggesting that there be
a flag for mutexes that label them as a 'leaf' mutex. By which I mean
the mutex 'call graph' will never see thes as anything as a
terminal node. Netgraph has no problems with using mutexes in this way,
but getting on a chain of mutexes some of which may take a while to 
clear ca totally screw it's usefulness.