From owner-cvs-all@FreeBSD.ORG Mon Sep 5 16:43:43 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 445BB16A41F; Mon, 5 Sep 2005 16:43:43 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 097CA43D45; Mon, 5 Sep 2005 16:43:42 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j85GhfEa023991; Mon, 5 Sep 2005 09:43:41 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j85Ghfaq023990; Mon, 5 Sep 2005 09:43:41 -0700 (PDT) (envelope-from rizzo) Date: Mon, 5 Sep 2005 09:43:41 -0700 From: Luigi Rizzo To: Gleb Smirnoff Message-ID: <20050905094341.A23343@xorpc.icir.org> References: <200509051602.j85G2Bpo090258@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200509051602.j85G2Bpo090258@repoman.freebsd.org>; from glebius@FreeBSD.org on Mon, Sep 05, 2005 at 04:02:11PM +0000 Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_poll.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2005 16:43:43 -0000 gleb, could you document how you are using the PRF_RUNNING and PRF_LEAVING flags that you added ? also i am unclear on whether there is a race condition involving unregistering poll (second part of netisr_poll()) while running the section of ether_poll() where it drops the mutex before calling the handler. ether_poll signals its activity with PRF_RUNNING, but netisr_poll() does not check it, so it might happen that 1. on one CPU, ether_poll() drops the lock before calling pr[i].handler(), perhaps even getting descheduled 2. on another CPU, netisr_poll() gets the lock and goes all the way to the end, setting pr[i].handler = NULL 3. on the first CPU, without further checks, the code tries to dereference the field. Also, what is the overall design - do you want to support multiple polling loops running concurrently (netisr_poll, one poll_idle per CPU, and possibly the poll_in_trap) ? cheers luigi