Date: Thu, 25 Sep 2008 21:51:00 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Stefan Ehmann <shoesoft@gmx.net> Cc: freebsd-current@freebsd.org Subject: Re: ipfw: LOR/panic with uid rules Message-ID: <alpine.BSF.1.10.0809252149560.18227@fledge.watson.org> In-Reply-To: <200809250139.10332.shoesoft@gmx.net> References: <200809231851.42849.shoesoft@gmx.net> <200809250020.38331.shoesoft@gmx.net> <alpine.BSF.1.10.0809242342440.68287@fledge.watson.org> <200809250139.10332.shoesoft@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 25 Sep 2008, Stefan Ehmann wrote:
> Hmm, just obtained a new dump which was the same. Did a normal "make
> kernel", so source/kernel should be in sync
>
> This is the version:
>
> __FBSDID("$FreeBSD: src/sys/netinet/tcp_input.c,v 1.382 2008/09/24 11:07:03
> rwatson Exp $");
>
> What doesn't match? I only checked this and it looks okay to me
Indeed, it looks like I had my own source synchronization issue :-).
This backtrace is differen from the previous one, and is for a different
instance of the same bug. I believe I've corrected it with this change:
rwatson 2008-09-25 17:26:54 UTC
FreeBSD src repository
Modified files:
sys/netinet tcp_input.c
Log:
SVN rev 183356 on 2008-09-25 17:26:54Z by rwatson
As a follow-on to r183323, correct another case where ip_output() was
called without an inpcb pointer despite holding the tcbinfo global
lock, which lead to a deadlock or panic when ipfw tried to further
acquire it recursively.
Reported by: Stefan Ehmann <shoesoft at gmx dot net>
MFC after: 3 days
Revision Changes Path
1.383 +17 -1 src/sys/netinet/tcp_input.c
Could you update and see if things run better?
Thanks,
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?alpine.BSF.1.10.0809252149560.18227>