Date: Fri, 20 Jul 2007 11:17:39 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Max Laier <max@love2party.net> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-pf@freebsd.org, freebsd-arch@freebsd.org Subject: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) Message-ID: <20070720111539.U1096@fledge.watson.org> In-Reply-To: <200707172342.39082.max@love2party.net> References: <20070717131518.G1177@fledge.watson.org> <200707172342.39082.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 Jul 2007, Max Laier wrote: > [ Excess CC-list ... testers needed!!! ] > > On Tuesday 17 July 2007, Robert Watson wrote: >> Dear all: >> >> 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 [1]. Everything different to those should > be reported. 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 Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070720111539.U1096>