Network stack locking question

[Ivo Vachkov]

On 9/4/07, Bruce M. Simpson <bms at freebsd.org> wrote:
>
> 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.

ether_demux() calls my_func() directly. my_func() can consume the
packet or return it to the ether_demux(). ether_input() does not
appear in the call trace.

> 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?

My lookup code looks like the following:

	struct sockaddr_in6 *dst = NULL;
	struct route_in6 out_rt;

        /* ... */

	dst = (struct sockaddr_in6 *)&out_rt.ro_dst;
	bzero(dst, sizeof(*dst));
	dst->sin6_len = sizeof(struct sockaddr_in6);
	dst->sin6_family = AF_INET6;
	dst->sin6_addr = ip6->ip6_dst;

	rtalloc((struct route *)&out_rt);

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

i do not call ether_demux() myself

> regards,
> BMS
>

thank you for the time and the help.