From owner-freebsd-current@FreeBSD.ORG Tue Jul 3 14:54:00 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2E2B16A479 for ; Tue, 3 Jul 2007 14:54:00 +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 7AE8013C4F8 for ; Tue, 3 Jul 2007 14:54:00 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id AC8C465A2; Tue, 3 Jul 2007 10:34:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 03 Jul 2007 10:34:35 -0400 X-Sasl-enc: OMUlNKMpjnDr5w5RDkvJMe+wSkCILWDerGiFmHzsQrfn 1183473275 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 D1DFC139E; Tue, 3 Jul 2007 10:34:34 -0400 (EDT) Message-ID: <468A5E79.10407@FreeBSD.org> Date: Tue, 03 Jul 2007 15:34:33 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Robert Watson References: <20070703143617.D29272@fledge.watson.org> In-Reply-To: <20070703143617.D29272@fledge.watson.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian FREISLICH , freebsd-current@freebsd.org, bu7cher@yandex.ru Subject: Re: Panic in ipfw X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 03 Jul 2007 14:54:00 -0000 Robert Watson wrote: > > My hope is that these will be addressed in FreeBSD 8.x, especially > with the upcoming read-mostly locks, which will have almost zero cost > to acquire for read protection, exactly what we'd like to see for > these code paths. Some of these changes may be mergeable to the 7.x > branch, but will need lots of time to "burn in", as the risks of such > changes are non-trivial. I did some initial work to properly lock down > the ifaddr address lists for netinet, and found they required moderate > rearrangement of the address management ioctl paths, which are pretty > complex without being rerranged :-). How do you feel about taking protocol domain addresses out of struct ifnet altogether? Logically they belong with other protocol domain state, and this would likely eliminate another swathe of locking and general ordering issues, although it would come at the cost of ABI compatibility and a change in userland tools. Right now there is no way of purging protocol domain state e.g. for IPv6 without taking an interface out of the system completely. This is not possible for onboard hardware unless the underlying driver is built as a module. Regards, BMS