From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 16:42:17 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 EE3D016A41F; Thu, 10 Nov 2005 16:42:17 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5150043D60; Thu, 10 Nov 2005 16:42:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1709437 for multiple; Thu, 10 Nov 2005 11:44:21 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jAAGg7p1066514; Thu, 10 Nov 2005 11:42:12 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 10 Nov 2005 11:40:13 -0500 User-Agent: KMail/1.8.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511101140.15374.jhb@freebsd.org> X-Spam-Status: No, score=-2.2 required=4.2 tests=ALL_TRUSTED,URIBL_SBL autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: max@love2party.net, snezhko@indorsoft.ru, 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 16:42:18 -0000 On Thursday 10 November 2005 10:40 am, SUZUKI Shinsuke wrote: > >>>>> On Thu, 10 Nov 2005 16:54:34 +0600 > >>>>> snezhko@indorsoft.ru(Victor Snezhko) said: > > > > Mark Tinguely has found the offending timer. > > The following patch fixes the problem for me: > > Thanks. sounds right for me. > So please commit it if when you've finished the test with fresh -current. As a general rule you should be using callout_drain() before freeing a callout to handle the race condition where the callout is running on another CPU (so callout_stop can't stop it) while you are freeing it. Note that you can not use callout_drain() if you are holding any locks, though. In those cases you will need to defer the callout_drain() and free() until you have dropped the locks. Here's one example fix: Index: nd6.c =================================================================== RCS file: /usr/cvs/src/sys/netinet6/nd6.c,v retrieving revision 1.62 diff -u -r1.62 nd6.c --- nd6.c 22 Oct 2005 05:07:16 -0000 1.62 +++ nd6.c 3 Nov 2005 19:56:42 -0000 @@ -398,7 +398,7 @@ if (tick < 0) { ln->ln_expire = 0; ln->ln_ntick = 0; - callout_stop(&ln->ln_timer_ch); + callout_drain(&ln->ln_timer_ch); } else { ln->ln_expire = time_second + tick / hz; if (tick > INT_MAX) { -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org