From owner-freebsd-net@FreeBSD.ORG Tue Jul 12 15:25:02 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 D89DB16A41C for ; Tue, 12 Jul 2005 15:25:02 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 364CD43D45 for ; Tue, 12 Jul 2005 15:25:01 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru (8.13.0/vak/3.0) id j6CFLD6q081272 for freebsd-net@freebsd.org.checked; Tue, 12 Jul 2005 19:21:13 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from [144.206.181.94] (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru (8.13.0/vak/3.0) with ESMTP id j6CFJXJq081261; Tue, 12 Jul 2005 19:19:33 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <42D3DF85.5090501@cronyx.ru> Date: Tue, 12 Jul 2005 19:19:33 +0400 From: Roman Kurakin User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ed Maste References: <42CEF0EB.4000107@borderware.com> <42D006DB.8080108@errno.com> <20050712150224.GA38249@sandvine.com> In-Reply-To: <20050712150224.GA38249@sandvine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Leffler , ming fu , freebsd-net@freebsd.org 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:25:03 -0000 Ed Maste wrote: >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. > > Some code that contains splXXX is working under global GIANT lock. Some splXXX left for reference, just in case. (As in if_spppXXX). But work in progress and I hope that before 7.0 all code would be fixed. rik >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 >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >