Date: Wed, 5 Sep 2007 12:16:40 +0300 From: "Ivo Vachkov" <ivo.vachkov@gmail.com> To: freebsd-net <freebsd-net@freebsd.org> Subject: Re: Network stack locking question Message-ID: <f85d6aa70709050216j72d8d2f4qce46e65e675a8ee3@mail.gmail.com> In-Reply-To: <46DD2A1E.3060109@FreeBSD.org> References: <f85d6aa70709040234w3abc3e05n9cf9c9d86cb994cd@mail.gmail.com> <46DD2A1E.3060109@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/4/07, Bruce M. Simpson <bms@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f85d6aa70709050216j72d8d2f4qce46e65e675a8ee3>