Ivo Vachkov wrote:
panic: mtx_lock() of spin mutex 'some_strange_chars' ../../../net/route.c:114
ether_demux() at ether_demux+
my_func() at my_func+
rtalloc_ign() at rtalloc_ign+
_mtx_lock_flags() at _mtx_lock_flags+
panic() at panic+
I do not include GIANT_REQUIRED in my code. Can you propose a solution
or a pointer to information where I can make myself familiar with the
networking code locking ... besides 'man 9 locking' and related.
It really isn't as simple as 'read this doc' because the code is subject
to change - the code *is* the reference - it is constantly evolving. If
you want to contribute docs, please feel free, Robert may have something
lying around.
How is ether_demux() calling your function, and does ether_input()
appear in this call trace? This is counterintuitive and I don't really
have enough data to go on.
Looking at the code, it seems your backtrace hits the RTFREE() call when
trying to allocate an rtentry through rtalloc_ign(), are you attempting
to cache the results of a previous call which may still be locked?
On a more general note.
I suggest is that you *do not* hold any locks when calling ether_demux()
for whatever reason. I wouldn't recommend calling that function directly
- the only things outside of the ethernet paths which do this are
dummynet and netgraph. tap(4) doesn't - it dispatches through ether_input().
When re-entering the bottom of the stack in this way, you *should not*
hold any locks. rtalloc_ign() currently acquires a lock on its rtentry
by default, please release it before reentering the bottom half of the
network stack.
regards,
BMS
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
