From owner-freebsd-current Mon Jul 8 12:27:40 2002 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 B374B37B401 for ; Mon, 8 Jul 2002 12:27:37 -0700 (PDT) Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id EECDB43E3B for ; Mon, 8 Jul 2002 12:27:35 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7237 invoked from network); 8 Jul 2002 19:27:34 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Jul 2002 19:27:34 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g68JRWf05211; Mon, 8 Jul 2002 15:27:32 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020704132044.7338.qmail@web20909.mail.yahoo.com> Date: Mon, 08 Jul 2002 15:27:38 -0400 (EDT) From: John Baldwin To: David Xu Subject: Re: Timeout and SMP race Cc: freebsd-current@FreeBSD.ORG, julian@elischer.org, Bruce Evans Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04-Jul-2002 David Xu wrote: > in RELENG_4, when one calls callout_stop() (not nested in softclock execute > path > , I am not talking about this case), after it returns, he can believe that the > callout is truely stopped, however in CURRENT, this assumption is false, now we > > must care if callout_stop() truely stopped the callout when it returned, this > is all difference I see, we bring in this race which not exists in RELENG_4, > see what hacking code put in kern_condvar.c and kern_synch.c in CURRENT source, In 4.x we don't support concurrent threads in the kernel either, so of course we have new races to deal with. Unfortunately there is no good way to reliably try to synchronize callout_stop() with softclock(). The callout function may reuse the callout structure associated with it, so we can't use that callout structure to save any state across the call. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message