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

Alfred Perlstein alfred at freebsd.org
Sun Jan 25 00:54:06 PST 2009


* 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.

-- 
- Alfred Perlstein


More information about the freebsd-current mailing list