From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 14:50:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A2F016A41F; Thu, 10 Nov 2005 14:50:43 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2572943D48; Thu, 10 Nov 2005 14:50:43 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id jAAEobHs057634; Thu, 10 Nov 2005 08:50:37 -0600 (CST) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id jAAEobjn057630; Thu, 10 Nov 2005 08:50:37 -0600 (CST) (envelope-from tinguely) Date: Thu, 10 Nov 2005 08:50:37 -0600 (CST) From: Mark Tinguely Message-Id: <200511101450.jAAEobjn057630@casselton.net> To: bug-followup@freebsd.org, snezhko@indorsoft.ru In-Reply-To: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on ccn.casselton.net Cc: max@love2party.net, freebsd-current@freebsd.org, Max@freebsd.org Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 14:50:43 -0000 As a postscript: The problem was a dynamic timer was freed without being stopped first. Obviously, the printf() should be removed from the final fix. After this discovery, I went through all of the callout_init() calls in the kernel and looked at those that may be freed before possibly being stopped. Beside the one in netinet6/mld6.c, I have 5 more that initially look like the memory for the callout struction could also be freed and still not have been stopped. These paths are problably not traveled much (detaches for less mainstream components), but stopping the callout is cheap and not at all risky. I will look at the 5 cases again and suggest all of these callout at risk be stopped under the same fix. --Mark Tinguely