[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0)
- To: Max Laier <max_(_at_)_love2party_(_dot_)_net>
- Subject: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0)
- From: Robert Watson <rwatson_(_at_)_FreeBSD_(_dot_)_org>
- Date: Fri, 20 Jul 2007 11:17:39 +0100 (BST)
- Cc: freebsd-net_(_at_)_freebsd_(_dot_)_org, freebsd-current_(_at_)_freebsd_(_dot_)_org, freebsd-pf_(_at_)_freebsd_(_dot_)_org, freebsd-arch_(_at_)_freebsd_(_dot_)_org
On Tue, 17 Jul 2007, Max Laier wrote:
[ Excess CC-list ... testers needed!!! ]
On Tuesday 17 July 2007, Robert Watson wrote:
This is a reminder e-mail that, in the very near future, Giant
compatibility shims for network protocols will be removed.
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.
What we really need right now, is real understanding of the problem (if
there even is any). So we would like to ask everybody who is able to - to
stress test user/group rules (in pf) or uid/gid/jail rules (in ipfw) with
debug.mpsafenet=1 It is normal that (in an WITNESS enabled kernel) you get a
LOR similar to 14-17 and 32 from . Everything different to those should
So far I have had 0 (zero) reports of problems since this thread began.
Could people using uid/gid/jail rules with ipfw or pf on 7.x *please* try
running their firewalls without debug.mpsafenet -- ignore the witness warnings
and/or disable witness, and let us know if you experience deadlocks. We're
reaching the very end of the merge cycle for 7.0, and I would really like to
remove the Giant crutches (now effectively unused) from the network stack so
it's not part of the ABI/API, the code is simplified and cleaned up, etc.
We'll need to figure out the best way to suppress these witness warnings
without suppressing too many other things still.
Robert N M Watson
University of Cambridge
freebsd-current_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe_(_at_)_freebsd_(_dot_)_org"