From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 22:10:03 2008 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4CE91065689 for ; Sat, 27 Sep 2008 22:10:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 90EA28FC0A for ; Sat, 27 Sep 2008 22:10:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 29E7A46B39 for ; Sat, 27 Sep 2008 18:10:03 -0400 (EDT) Date: Sat, 27 Sep 2008 23:10:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: stable@FreeBSD.org Message-ID: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Warning: known instability using ipfw "uid" rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2008 22:10:03 -0000 An FYI: In the past couple of days, presumably as testing of 7.x becomes more widespread, I've seen several reports of instability resulting from ipfw credential rules. For those unfamiliar with them, these allow the matching of packets in ipfw rules based on the credentials of the socket that generated them, or the credentials of the socket that likely will receive them. These problems are a side effect of elimating support for lock recursion on inpcbinfo locks as part of the UDP performance optimization work for 7.1. There are two minor TCP fixes, and a more serious ipfw bug fix, in the queue to be MFC'd in the next couple of days. Once they're fixed, please make sure any further problems with deadlocks or panics involving ipfw rules are brought to my attention. Thanks, and apologies for any inconvenience -- this issue did not arise during testing in HEAD over the course of several months, but fortunately appears fairly straight forward to resolve now that it's a bit better understood. Robert N M Watson Computer Laboratory University of Cambridge