From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 15:02:27 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F1CE16A41C for ; Tue, 12 Jul 2005 15:02:27 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id D76F343D49 for ; Tue, 12 Jul 2005 15:02:26 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Jul 2005 11:02:24 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id D47E61364F; Tue, 12 Jul 2005 11:02:24 -0400 (EDT) Date: Tue, 12 Jul 2005 11:02:24 -0400 From: Ed Maste To: Sam Leffler Message-ID: <20050712150224.GA38249@sandvine.com> References: <42CEF0EB.4000107@borderware.com> <42D006DB.8080108@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42D006DB.8080108@errno.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 12 Jul 2005 15:02:25.0004 (UTC) FILETIME=[B66272C0:01C586F2] Cc: freebsd-net@freebsd.org, ming fu Subject: Re: what to replace splnet in FreeBSD 5.x? 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, 12 Jul 2005 15:02:27 -0000 On Sat, Jul 09, 2005 at 10:18:19AM -0700, Sam Leffler wrote: > spl's lock execution threads. 5.x and later systems mostly lock data > structures using mtx's (there are a very few exceptions). Thus there > isn't necessarily a direct replacement, you usually need to rethink your > locking/synchronization strategy. This brings up the issue of the remaining splnet()s in 5.x and -CURRENT. Grepping for "= splnet" in net/ and netinet/ shows more than 50 now no-op splnet()s left in the stack. We've run into corruption in the multicast address lists (in_multihead) on 5.x, and it turns out in_addmulti still has splnet() "protecting" the list. I'm not sure how many of the splnet()s are actually false positives (i.e. no longer relevant, locked in another way, etc.) but they're probably all good indicators of places that locking still needs to be revisited. -- Ed Maste, Sandvine Incorporated