Running the network stack without Giant -- change in default
coming
Robert Watson
rwatson at FreeBSD.org
Tue Aug 24 19:13:05 PDT 2004
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
More information about the freebsd-current
mailing list