On 9/4/07, Bruce M. Simpson <[EMAIL PROTECTED]> 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.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
