Date: Fri, 27 Jul 2007 09:43:53 +0200 From: Max Laier <max@love2party.net> To: Kris Kennaway <kris@obsecurity.org> Cc: Robert Watson <rwatson@freebsd.org>, Julian Elischer <julian@elischer.org>, freebsd-arch@freebsd.org Subject: Re: Attention pf/ipfw users with uid/gid/jail rules (Re: Reminder: NET_NEEDS_GIANT, debug.mpsafenet going away in 7.0) Message-ID: <200707270944.08668.max@love2party.net> In-Reply-To: <20070727024107.GA69300@rot26.obsecurity.org> References: <20070717131518.G1177@fledge.watson.org> <46A100C2.1030606@elischer.org> <20070727024107.GA69300@rot26.obsecurity.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Friday 27 July 2007, Kris Kennaway wrote:
> On Fri, Jul 20, 2007 at 11:36:50AM -0700, Julian Elischer wrote:
> > Robert Watson wrote:
> > >On Tue, 17 Jul 2007, Max Laier wrote:
> > >
> > >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.
> >
> > does "problem" include a LOR message, or only a deadlock?
> > I've seen plenty of the first, but not the second.
>
> Various users have reported definite deadlocks relating to uid/gid
^------^ ^------^
> firewall rules in the past.
I don't think the strong wording is true. I have seen a few reports of
deadlocks in the past where debug.mpsafenet "fixed" the issue, but none
of the reporters where able to provide enough debugging details to
actually identify the culprit.
Also note that a lot has changed since the early reports. What WITNESS is
warning about now is something like:
rlock(&lock1);
mtx_lock(&lock2);
mtx_unlock(&lock2);
runlock(&lock1);
vs.
mtx_lock(&lock2);
rlock(&lock1);
runlock(&lock1);
mtx_unlock(&lock2);
It's obvious that this can't cause a deadlock unless there is a third
codepath that does either:
wlock(&lock1);
mtx_lock(&lock2);
mtx_unlock(&lock2);
wunlock(&lock1);
or
mtx_lock(&lock2);
wlock(&lock1);
wunlock(&lock1);
mtx_unlock(&lock2);
I have an idea how to teach WITNESS about this, but it's an awful hack,
yet.
--
/"\ Best regards, | mlaier@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQBGqaJIXyyEoT62BG0RAm1aAJ9odYqxJEIjxEMrbr+bG2r3jC5TsQCaAr5+
9fVT+KOkkxdub/q9NyqKoj4=
=mAop
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707270944.08668.max>