From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 10 01:49:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4DA937B401 for ; Thu, 10 Jul 2003 01:49:41 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E87A543F85 for ; Thu, 10 Jul 2003 01:49:39 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h6A8naQ22665; Thu, 10 Jul 2003 10:49:36 +0200 (MEST) Date: Thu, 10 Jul 2003 10:49:36 +0200 (CEST) From: Harti Brandt To: Eric Jacobs In-Reply-To: <20030709171940.1366084b.eaja@erols.com> Message-ID: <20030710104116.N30571@beagle.fokus.fraunhofer.de> References: <20030709150708.O30571@beagle.fokus.fraunhofer.de> <20030709171940.1366084b.eaja@erols.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Race in kevent X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2003 08:49:42 -0000 On Wed, 9 Jul 2003, Eric Jacobs wrote: EJ>On Wed, 9 Jul 2003 15:28:38 +0200 (CEST) EJ> EJ>I didn't think of it in my original post, but perhaps we need a EJ>"thissoftcheck" pointer that works analogously to "nextsoftcheck", EJ>except that instead of being advanced to the next entry in the queue, EJ>it is simply zeroed out when the entry is removed. softclock() could EJ>detect this pointer being zeroed out just before it goes to call the EJ>callout or timeout function and skip that invocation if that is the EJ>case. EJ> EJ>This is definitely not a solution in the CALLOUT_MPSAFE case, however, EJ>because it would make no sense to try to verify this pointer in the EJ>unprotected area between the spin lock being dropped and the sleep EJ>lock being picked up. In the !CALLOUT_MPSAFE case, we know what the EJ>sleep mutex would be -- it is always Giant -- and so we can test the EJ>pointer after that point. EJ> EJ>I am still not certain I am thinking clearly about this. I think for the MPSAFE case we should just make the callout flags to be correct (look at CALLOUT_ACTIVE) so that a caller has a chance to find out the current state of the callout. Otherwise the user of an MPSAFE callout should avoid races. This means: clearing CALLOUT_ACTIVE in softclock() after the callout has returned and the lock has been re-aquired. Probably returning without doing anything from callout_stop() when it finds the callout to be non-pending but active. For the !MPSAFE case, however, we should do something. I think your idea would work. The only problem I can see are wrong uses of callouts allocated by timeout() (for an example see dev/ray/if_ray.c). These should be fixed in the callers of timeout(9). Could you craft a patch? I would try it. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org