[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0
- To: current_(_at_)_FreeBSD_(_dot_)_org, arch_(_at_)_FreeBSD_(_dot_)_org
- Subject: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0
- From: Robert Watson <rwatson_(_at_)_FreeBSD_(_dot_)_org>
- Date: Tue, 17 Jul 2007 13:21:36 +0100 (BST)
- Cc:
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
_______________________________________________
freebsd-current_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org