Date: Tue, 17 Jul 2007 13:21:36 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: current@FreeBSD.org, arch@FreeBSD.org Subject: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0 Message-ID: <20070717131518.G1177@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Dear all:
This is a reminder e-mail that, in the very near future, Giant compatibility
shims for network protocols will be removed. These shimmed allowed Giant to
be re-enabeld over the network stack as a result of linking in a service that
required Giant (now all removed), or by setting the debug.mpsafenet variable
to 1. This means that the following will no longer be present:
debug.mpsafenet sysctl
debug_mpsafenet global variable
NET_NEEDS_GIANT()
NET_LOCK_GIANT(), NET_UNLOCK_GIANT(), NET_ASSERT_GIANT()
NET_CALLOUT_MPSAFE
All instances of NET_{LOCK,UNLOCK,ASSERT}_GIANT() will be removed as they will
no be no-ops.
The (unused) definition of NET_NEEDS_GIANT() will be removed. The
debug.mpsafenet sysctl and debug_mpsafenet global variable will be removed.
All instances of NET_CALLOUT_MPSAFE will be converted mechanically to
CALLOUT_MPSAFE.
The *only* remaining case I am aware of where removing debug.mpsafenet
presents an issue is credential-related firewall rules (uid, gid, jail). I'm
am currently in an active e-mail discussion with the various firewall
maintainers about how to address this issue; as the implementations of these
rules violate the global lock order, deadlocks occur if debug.mpsafenet isn't
set to 1, which causes Giant to act as a guard lock preventing parallel lock
acquisition in the firewall. Hopefully we will have this resolved, in some
form, soon.
I will remove the above in a series of commits; the only complicated bits are
removing the NET_*_GIANT() calls from the socket system call code, where they
made things quite a bit more complex than desirable due to additional error
handling and unwinding, and in the Cronyx drivers, which interact with
debug_mpsafenet in unusual ways (disabling their own locking when Giant is
present). Otherwise, this is a fairly low-risk change in practice, since 99%
of FreeBSD users have been running without Giant over the network stack since
5.4 (or was it 5.3?).
Robert N M Watson
Computer Laboratory
University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070717131518.G1177>