Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jun 2006 09:30:00 +0000 (UTC)
From:      "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
To:        Max Laier <max@love2party.net>
Cc:        Brad Waite <freebsd@wcubed.net>, freebsd-stable@freebsd.org
Subject:   Re: 6.1-stable hangs and LORs
Message-ID:  <20060612092830.V79180@maildrop.int.zabbadoz.net>
In-Reply-To: <200606120024.59336.max@love2party.net>
References:  <448C5C41.10302@wcubed.net> <20060611213635.GA35430@xor.obsecurity.org> <448C8F3B.5020806@wcubed.net> <200606120024.59336.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Jun 2006, Max Laier wrote:

> On Sunday 11 June 2006 23:46, Brad Waite wrote:
>> Kris Kennaway wrote:
>>> We need to know the LOR before anyone can tell what is going wrong ;-)
>>
>> Ask and you will receive:
>>
>> lock order reversal:
>>   1st 0xc077a440 pf task mtx (pf task mtx) @
>> /usr/src/sys/contrib/pf/net/pf.c:6331
>>   2nd 0xc07d3fac tcp (tcp) @ /usr/src/sys/contrib/pf/net/pf.c:2719
>
> From pf.conf(5):
> BUGS
>     Due to a lock order reversal (LOR) with the socket layer, the use of the
>     group and user filter parameter in conjuction with a Giant-free netstack
>     can result in a deadlock.  If you have to use group or user you must set
>     debug.mpsafenet to ``0'' from the loader(8), for the moment.  This work-
>     around will still produce the LOR, but Giant will protect from the dead-
>     lock.

though this is known and there are already other similar LORs (like
#17, ...) I added it to the LOR page with ID 191 because it's another
code path in the backtrace. That way people will also find this one.
 	http://sources.zabbadoz.net/freebsd/lor.html#191

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060612092830.V79180>