From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 17:03:01 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 9FAF316A429; Thu, 10 Nov 2005 17:03:01 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 028F743D45; Thu, 10 Nov 2005 17:02:59 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000029142.msg; Thu, 10 Nov 2005 23:02:52 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 127012, updated: 9.11.2005] To: Mark Tinguely References: <200511101450.jAAEobjn057630@casselton.net> From: Victor Snezhko Date: Thu, 10 Nov 2005 23:02:47 +0600 In-Reply-To: <200511101450.jAAEobjn057630@casselton.net> (Mark Tinguely's message of "Thu, 10 Nov 2005 08:50:37 -0600 (CST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Thu, 10 Nov 2005 23:02:52 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-VVS-Spam: false Cc: max@love2party.net, freebsd-current@freebsd.org, Max@freebsd.org, bug-followup@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 17:03:01 -0000 Mark Tinguely writes: > 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. Not risky? I'm not an expert, but I think there might be issues when callout is stopped at the moment when on-timer function is executed (I see the following bad scenario: timer function begins to execute, then we call callout_stop(), then free all the necessary data structures and then control returns to the timer proc which could depend on the structures that are already freed) I.e. in each case we should check if callout_stop don't harm. On the other hand, callout_drain could introduce lock order issues (as John Baldwin pointed). > I will look at the 5 cases again and suggest all of these callout at > risk be stopped under the same fix. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru