From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 17:19:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC12F1065673 for ; Tue, 23 Sep 2008 17:19:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 62C2F8FC1A for ; Tue, 23 Sep 2008 17:19:15 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so551502eyi.7 for ; Tue, 23 Sep 2008 10:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1PkdHgcMT3dzRVOss1tc5tBa6uLOVBzY6zFgMacOUzk=; b=v/UXhw1xFVezdAH74hHBtrNLsmIsN0FjpImduZSz99YQlIAg2rZaIspXPJZkDZsFf7 Qi+Vo4Le9/d5veA+SWDH0WmBo+a+AFmznHXZ+A+4aTEkzUv0b52Rf4kYyQQf3FZMg8PC unCDYcrob4xLBZVdXpxzdEOkSMToNlyMonze0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ExyT7LLjAVc98gigpjL6Er1X7gvCPMUPPPlYcZrRAAG2iuVEg7qLQfrPGfcZkZ3QiZ ygCRKMV9emwQY22BiYajwrXwWHxCgJ1NPrfgN8I/Qeo29t5xeY88hUBtkvw7Yr3yKu79 i9uwiqqqMk8chHXAK8sOVWCVYucJNRaNvEl+I= Received: by 10.86.79.19 with SMTP id c19mr6343240fgb.79.1222190354047; Tue, 23 Sep 2008 10:19:14 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Tue, 23 Sep 2008 10:19:13 -0700 (PDT) Message-ID: Date: Tue, 23 Sep 2008 10:19:13 -0700 From: "Maksim Yevmenkin" To: "Kostik Belousov" In-Reply-To: <20080923094134.GM47828@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D2F942.4070801@FreeBSD.org> <20080919084201.GD44330@wep4035.physik.uni-wuerzburg.de> <48D38DFF.8000803@FreeBSD.org> <20080919203310.GA34131@localhost.my.domain> <48D8196E.7020005@FreeBSD.org> <20080923094134.GM47828@deviant.kiev.zoral.com.ua> Cc: Alexey Shuvaev , freebsd-current@freebsd.org, Ed Schouten Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2008 17:19:16 -0000 On 9/23/08, Kostik Belousov wrote: [...] > > attached is a slightly better patch for tap(4). the idea is to use > > extra ALLOCATED flag that prevents the race Kostik pointed out. could > > you please give it a try? any review comments are greatly appreciated. > > if this is acceptable, i will prepare something similar for tun(4) > > The tap should use make_dev_credf(MAKEDEV_REF) instead of > make_dev/dev_ref sequence in the clone handler. For similar reasons, I > think it is slightly better to do a dev_ref() immediately after setting > the TAP_ALLOCATED flag without dropping tapmtx. could you please explain why it is better? > I cannot figure out how tap_clone_create/tap_clone_destroy are being > called. Can it be garbage-collected ? ah, this is interface clone feature, i.e. one can do 'ifconfig tap0 create/destroy' to create an interface and device node. take a look at IFC_SIMPLE_DECLARE() macro. > The whole module unload sequence looks unsafe. yes, it is unsafe. it even has comment about it :) i guess, i could fix it too while i'm at it :) thanks, max