From owner-freebsd-bugs@FreeBSD.ORG Thu Nov 10 15:00:25 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D011116A41F for ; Thu, 10 Nov 2005 15:00:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DE7243D48 for ; Thu, 10 Nov 2005 15:00:25 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jAAF0PvR041655 for ; Thu, 10 Nov 2005 15:00:25 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jAAF0PJN041654; Thu, 10 Nov 2005 15:00:25 GMT (envelope-from gnats) Date: Thu, 10 Nov 2005 15:00:25 GMT Message-Id: <200511101500.jAAF0PJN041654@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Mark Tinguely Cc: Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Tinguely List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 15:00:25 -0000 The following reply was made to PR kern/88725; it has been noted by GNATS. From: Mark Tinguely To: bug-followup@freebsd.org, snezhko@indorsoft.ru Cc: freebsd-current@freebsd.org, Max@freebsd.org, max@love2party.net Subject: Re: kern/88725: /usr/sbin/ppp panic with 2005.10.21 netinet6 changes Date: Thu, 10 Nov 2005 08:50:37 -0600 (CST) 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