From owner-freebsd-threads@FreeBSD.ORG Fri Sep 22 21:39:42 2006 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC5D616A403; Fri, 22 Sep 2006 21:39:42 +0000 (UTC) (envelope-from john@baldwin.cx) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BAEC43D58; Fri, 22 Sep 2006 21:39:41 +0000 (GMT) (envelope-from john@baldwin.cx) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8MLdYe6016440; Fri, 22 Sep 2006 17:39:37 -0400 (EDT) (envelope-from john@baldwin.cx) From: John Baldwin To: freebsd-threads@freebsd.org, John-Mark Gurney Date: Fri, 22 Sep 2006 17:39:32 -0400 User-Agent: KMail/1.9.1 References: <200609202105.k8KL5fh7081141@freefall.freebsd.org> <200609221425.02723.john@baldwin.cx> <20060922201336.GT23915@funkthat.com> In-Reply-To: <20060922201336.GT23915@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609221739.33091.john@baldwin.cx> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 22 Sep 2006 17:39:39 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1927/Fri Sep 22 06:06:31 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: anders@freebsd.org Subject: Re: kern/103127: Kernel panic while using thread features in Squid 2.6 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2006 21:39:42 -0000 On Friday 22 September 2006 16:13, John-Mark Gurney wrote: > John Baldwin wrote this message on Fri, Sep 22, 2006 at 14:25 -0400: > > On Thursday 21 September 2006 22:37, John-Mark Gurney wrote: > > > John Baldwin wrote this message on Thu, Sep 21, 2006 at 21:52 -0400: > > > > On Wednesday 20 September 2006 17:05, John-Mark Gurney wrote: > > > > > Synopsis: Kernel panic while using thread features in Squid 2.6 > > > > > > > > > > State-Changed-From-To: open->feedback > > > > > State-Changed-By: jmg > > > > > State-Changed-When: Wed Sep 20 21:04:55 UTC 2006 > > > > > State-Changed-Why: > > > > > waiting for people to test the patch of badfo_kqfilter that is attached > > > > > to the bug.. > > > > > > > > Should it possibly return EBADF rather than EINVAL? > > > > > > If we got this far, we have to have a valid fd, maybe ENXIO? > > > > badfo_* are used for bad (invalid) file descriptors. :) All the other badfo_* > > functions return EBADF (except for poll, since it returns an event mask > > rather than an errno). > > except we did have a valid fd since we did an fget on the > descriptor, and that would fail if it was bad: > if ((fp = fget_locked(fdp, fd)) == NULL || fp->f_ops == &badfileops) { > FILEDESC_UNLOCK(fdp); > return (EBADF); > } > > or can f_ops change in the middle? > > >From my reading it looks like it can can during a close, but if the > application is doing a simultanious close and attaching a knote, that's > a race condition, and we techincally still have a valid fd till was > can't fget the fd anymore... just MO of course... No, not really. We did an fget() and have a valid file pointer, but the file was closed in between fget() and using of the file. Once the file is closed, it's bad, and EBADF is the appropriate way to smack the userland app upside the head for its bug. -- John Baldwin