Re: Running the network stack without Giant -- change in default coming

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_at_fledge.watson.org      Principal Research Scientist, McAfee Research