From owner-freebsd-current@FreeBSD.ORG Sat Jun 21 08:39:49 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06D2337B401; Sat, 21 Jun 2003 08:39:49 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D2E743F75; Sat, 21 Jun 2003 08:39:48 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h5LFdbKJ033362; Sat, 21 Jun 2003 11:39:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h5LFdb5m033359; Sat, 21 Jun 2003 11:39:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 21 Jun 2003 11:39:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Hiten Pandya In-Reply-To: <20030621120809.GC5692@perrin.int.nxad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: locking problems in IPv6 code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2003 15:39:49 -0000 On Sat, 21 Jun 2003, Hiten Pandya wrote: > On Thu, Jun 19, 2003 at 03:17:03PM -0700, John-Mark Gurney wrote: > > I am running FreeBSD 5.1-R on a sparc64 machine, and am getting warnings > > about mallocing data w/ a lock aquired. > > > > dmesg output: > > malloc() of "64" with the following non-sleepablelocks held: > > exclusive sleep mutex netisr lock r = 0 (0xc0271890) locked @ net/netisr.c:215 > > For what it's worth, these warnings also appear if netisr direct > dispatch is enabled with the fxp(4) driver. These messages occur because our link layer address management code does mallocs with M_WAITOK. We need to teach that code to not wait when called from the interrupt path, and pass back up failure modes, or avoid holding locks while calling it. Probably the former, although the latter is also going to be good from a lock order perspective. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories