From owner-cvs-all@FreeBSD.ORG Sun Sep 18 17:00:48 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 2158D16A41F; Sun, 18 Sep 2005 17:00:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEA2543D45; Sun, 18 Sep 2005 17:00:47 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j8IGwKgq009676; Sun, 18 Sep 2005 10:58:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 18 Sep 2005 10:58:30 -0600 (MDT) Message-Id: <20050918.105830.20030981.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20050918163457.GA43796@ip.net.ua> References: <20050917101552.GC22151@ip.net.ua> <20050918030610.64B5616A420@hub.freebsd.org> <20050918163457.GA43796@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sun, 18 Sep 2005 10:58:21 -0600 (MDT) Cc: wpaul@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, jhb@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/dev/re if_re.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: Sun, 18 Sep 2005 17:00:48 -0000 In message: <20050918163457.GA43796@ip.net.ua> Ruslan Ermilov writes: : That's clear. I'm talking about fixing all drivers for the : BPF detach bug. The more I think about it, the more I think you may have been right about a flag. While I recoiled against it at first, I think that it is the only long term solution to these kinds of bugs. The reason I think this is that we have a number of races on detach. The bpf one is just an annoying one right now, but what if dhclient does an ioctl while we're detaching. What if there's an ifconfig done during the detach, etc. Sure, we can fix the bpf case using the complicated logic that was worked out here, but that still leaves a number of other races to worry about. If we're going to fix all the drivers in the tree, I think we should add a 'dying' flag that we could use for the ioctl (and other) requests to return an error and do nothing. The other option would be to move this up a layer. For device nodes, for example, we connect them to deadfs early in the destruction process. If we did something similar to the ifnet entry points, then we would fix all the drivers with one fell swoop, rather than doing it piecemeal. Warner