Date: Mon, 12 Jun 2006 00:24:51 +0200 From: Max Laier <max@love2party.net> To: freebsd-stable@freebsd.org Cc: Brad Waite <freebsd@wcubed.net>, Kris Kennaway <kris@obsecurity.org> Subject: Re: 6.1-stable hangs and LORs Message-ID: <200606120024.59336.max@love2party.net> In-Reply-To: <448C8F3B.5020806@wcubed.net> References: <448C5C41.10302@wcubed.net> <20060611213635.GA35430@xor.obsecurity.org> <448C8F3B.5020806@wcubed.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2480951.tsngEL0g3q
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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
> KDB: stack backtrace:
> witness_checkorder(c07d3fac,9,c06fd2f7,a9f) at witness_checkorder+0x55c
> _mtx_lock_flags(c07d3fac,0,c06fd2f7,a9f,c07d3fac) at _mtx_lock_flags+0x40
> pf_socket_lookup(e35ccacc,e35ccad0,1,e35ccb8c,0) at pf_socket_lookup+0x103
> pf_test_tcp(e35ccb3c,e35ccb34,1,c4d3e400,c5027c00,14,c5032810,e35ccb8c,e3=
5c
>cb40,e35ccb44,0,0) at pf_test_tcp+0x10d6
> pf_test(1,c4ba3c00,e35ccc2c,0,0) at pf_test+0xb77
> pf_check_in(0,e35ccc2c,c4ba3c00,1,0) at pf_check_in+0x37
> pfil_run_hooks(c07d3b60,e35ccccc,c4ba3c00,1,0) at pfil_run_hooks+0xee
> ip_input(c5027c00,18,c07d3138,e35cccec,c05dcd63) at ip_input+0x1b2
> netisr_processqueue(c4b24500,c4b28000,0,e35ccd0c,c055877b) at
> netisr_processqueue+0xf
> swi_net(0,c4b28038,c4ad6d80,c0558590,c4ad520c) at swi_net+0x8b
> ithread_loop(c4ab68d0,e35ccd38,c4ab68d0,c0558590,0) at ithread_loop+0x1eb
> fork_exit(c0558590,c4ab68d0,e35ccd38) at fork_exit+0x7d
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip =3D 0, esp =3D 0xe35ccd6c, ebp =3D 0 ---
=46rom pf.conf(5):
BUGS
Due to a lock order reversal (LOR) with the socket layer, the use of t=
he
group and user filter parameter in conjuction with a Giant-free netsta=
ck
can result in a deadlock. If you have to use group or user you must s=
et
debug.mpsafenet to ``0'' from the loader(8), for the moment. This wor=
k-
around will still produce the LOR, but Giant will protect from the dea=
d-
lock.
=2D-=20
/"\ Best regards, | mlaier@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
--nextPart2480951.tsngEL0g3q
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)
iD8DBQBEjJg7XyyEoT62BG0RAtTGAJ9jbegihTS7SX/IFTRiM7lbxVGo5QCaA/DG
DDzZ35Z0akefr1AY4U+izLA=
=/a6R
-----END PGP SIGNATURE-----
--nextPart2480951.tsngEL0g3q--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606120024.59336.max>