Date: Tue, 12 Jul 2005 19:19:33 +0400 From: Roman Kurakin <rik@cronyx.ru> To: Ed Maste <emaste@phaedrus.sandvine.ca> Cc: Sam Leffler <sam@errno.com>, ming fu <fming@borderware.com>, freebsd-net@freebsd.org Subject: Re: what to replace splnet in FreeBSD 5.x? Message-ID: <42D3DF85.5090501@cronyx.ru> In-Reply-To: <20050712150224.GA38249@sandvine.com> References: <42CEF0EB.4000107@borderware.com> <42D006DB.8080108@errno.com> <20050712150224.GA38249@sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42D3DF85.5090501>