From owner-freebsd-net@FreeBSD.ORG Tue Sep 4 09:49:20 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 D7C7416A418 for ; Tue, 4 Sep 2007 09:49:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7B7D913C491 for ; Tue, 4 Sep 2007 09:49:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 21CD327053; Tue, 4 Sep 2007 05:49:20 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 04 Sep 2007 05:49:20 -0400 X-Sasl-enc: CCJL+BdFrp1XXx3WT5aEivQ28jBk1AFJW57wKfvvbgHY 1188899359 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A03863472; Tue, 4 Sep 2007 05:49:19 -0400 (EDT) Message-ID: <46DD2A1E.3060109@FreeBSD.org> Date: Tue, 04 Sep 2007 10:49:18 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Ivo Vachkov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net 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: Tue, 04 Sep 2007 09:49:20 -0000 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