Network stack locking question

[Bruce M. Simpson]

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