Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0


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-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages