From owner-freebsd-net@FreeBSD.ORG Wed Sep 5 09:16:47 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAD3816A419 for ; Wed, 5 Sep 2007 09:16:47 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id 6924A13C48A for ; Wed, 5 Sep 2007 09:16:47 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1857203wxd for ; Wed, 05 Sep 2007 02:16:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=piOL0PxJLwYXXBNipNMxM/tu8Cvfx/j42gIvaFENx99q7xMdyI5nASNxdqa4G6Y2WlMtqFeyf73efKW/mgkwrc/STKLgoqte9OY7gPB9i0Uvdgpiay9nxutX4AS2JQ+qK5bSET4I0VzmEYvK77gI/E8iBF8rqmrqdQPvrB+Z9e4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pQ0OSz+87uViMOF8qILQJKu1dBrJ5rpSHYC1UXYIHCB/jP6nKDIC2oJTaQ5eaoy0RKlLK2zH7QbXfUT/bEcBvV6ti0H5valOJNXx7/21sH0u67dGu4fTJtJf1bpC/yGoA6Mmx9lacl/8Oa4RBH4/a4OFWhq7mEDEV3ptZlEH+vI= Received: by 10.90.66.9 with SMTP id o9mr6640713aga.1188983800519; Wed, 05 Sep 2007 02:16:40 -0700 (PDT) Received: by 10.90.114.13 with HTTP; Wed, 5 Sep 2007 02:16:40 -0700 (PDT) Message-ID: Date: Wed, 5 Sep 2007 12:16:40 +0300 From: "Ivo Vachkov" To: freebsd-net In-Reply-To: <46DD2A1E.3060109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46DD2A1E.3060109@FreeBSD.org> Subject: Re: Network stack locking question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2007 09:16:47 -0000 On 9/4/07, Bruce M. Simpson 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.