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

From: Maksim Yevmenkin <maksim.yevmenkin_at_gmail.com>
Date: Sat, 24 Jan 2009 17:33:24 -0800
On Sat, Jan 24, 2009 at 4:30 PM, Alfred Perlstein <alfred_at_freebsd.org> wrote:
> * Maksim Yevmenkin <maksim.yevmenkin_at_gmail.com> [090124 01:38] wrote:
>>
>> 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!
>
> 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.

thanks,
max
Received on Sun Jan 25 2009 - 00:33:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:41 UTC