From owner-freebsd-current@FreeBSD.ORG Wed Aug 25 02:13:05 2004 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 220B116A4CE for ; Wed, 25 Aug 2004 02:13:05 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 871C643D2F for ; Wed, 25 Aug 2004 02:13:04 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7P2AotM018295; Tue, 24 Aug 2004 22:10:50 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7P2AoFY018292; Tue, 24 Aug 2004 22:10:50 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 24 Aug 2004 22:10:49 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jun Kuriyama In-Reply-To: <7meklw6lnp.wl@black.imgsrc.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "George V.Neville-Neil" cc: current@FreeBSD.org Subject: Re: Running the network stack without Giant -- change in default coming 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: Wed, 25 Aug 2004 02:13:05 -0000 On Wed, 25 Aug 2004, Jun Kuriyama wrote: > At Tue, 24 Aug 2004 14:41:20 +0000 (UTC), > Robert Watson wrote: > > - We've focussed primarily on getting mainstream network configurations to > > run without Giant: this means that less mainstream subsystems (parts of > > IPv6, some netgraph nodes, IPX, etc) are currently unsafe without the > > Giant lock turned on. > > I'm interesting to use without Giant. But (as you know :-)) I'm using > IPv6 usually. How can I help to test this? > > I'm sorry I don't understand how it is difficult, but is it possible to > protect whole IPv6 code only with Giant without network stack Giant? Well, it's not impossible, but part of what would make it quite a bit more difficult than, for example, running with Giant over only IPX is that IPv4 and IPv6 share a substantial code base, APIs, and there are 46 sockets that use parts of both. I can imagine approaches to dealing with this, but I think a better strategy would be for us to complete the locking work on IPv6. George Neville-Neil and I have chatted some about our strategy towards completing IPv6 locking, and identified a number of areas of concern. At a high level, they are: - NFS over IPv6 still appears to be broken. We're not yet sure why, and we believe it's not a locking problem (rather, the disconnected NFS handling changes) but this needs to be resolved. - There may be remaining in6pcb locking nits, and we need to carefully review the in6pcb management code. A little reformulation to synch up with the inpcb code would be a good idea also. There are likely some more issues such as the ones you ran into with in6_pcbnotify(). - We need to review TCP/UDP locking, which was mirrored from the IPv4 code, but should probably be revisited. - if_gif requires locking work for IPv4 and IPv6. I have some work on this in the netperf branch, but it's only a starting point. - KAME IPSEC is currently not locked down. FAST_IPSEC is, but there are some nits, such as PF_KEY issues. I have some WIP in the netperf branch for correcting the PF_KEY issues, but have not yet tested it, so it will need more work. Some locking strategy for KAME IPSEC can be derived from FAST_IPSEC. - The existing locking in frag6 and scope6 needs to be reviewed and tested more. - The route locking in IPv6 needs reviewing. - IP6FW needs locking, perhaps in a style similar to ipfw for IPv4, although the code bases are now substantially diverged. Maybe with pf in the tree, we could drop ip6fw? - ip6_forward_rt needs locking; George is currently working on this. - ip6_mroute needs locking. - mld6 likely needs work. - ip6_id is unsynchronized, but so is ip_id. - raw_ip6 locking needs review and additional testing. George probably has an expanded version of the todo list. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research