From owner-freebsd-arch@FreeBSD.ORG Fri Jul 18 19:19:34 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF51E537 for ; Fri, 18 Jul 2014 19:19:33 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76CC4257D for ; Fri, 18 Jul 2014 19:19:33 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id n3so1347503wiv.13 for ; Fri, 18 Jul 2014 12:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=uH0f4VZiyxKN0kUqcp9EA1Xtxv67Dvpkoi7lbOTmkl4=; b=Cj5XlIHhIw3I/kaj4yAvwk1Lxa/r38tyrTSnAzdr/rbPYPQCERaGFIjfyMH2m0PZqw j+46sPrNULGq5LtNqRto2SGZb8g8eVWec0X1YZgsViWuxLCCCG99o65rZxKUtGH89vJ9 rY85EEbMKecnfau/nEahDOCTcHQ8dBaGXlQn2KTPh0klqPntZ+9YUqB8hNF7QmvwfZFa Ilbm2mS/FGqKnYqlWmlrmqoV2dGHxG+qAk85ha43YcG1bhtji6N7R4Qs0dm4F7APMGnd cLIPDNYFDaSvwypzJxFceZKLdnrNGibgJSo4jrAs5YxzMWylbL5RkHAKvbdYRdHXHn3C bE8Q== X-Received: by 10.194.48.8 with SMTP id h8mr9747673wjn.106.1405711171520; Fri, 18 Jul 2014 12:19:31 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hi4sm16294007wjc.27.2014.07.18.12.19.30 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 18 Jul 2014 12:19:30 -0700 (PDT) Date: Fri, 18 Jul 2014 21:19:28 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: current fd allocation idiom Message-ID: <20140718191928.GB7179@dft-labs.eu> References: <20140717235538.GA15714@dft-labs.eu> <20140718130629.GJ93733@kib.kiev.ua> <20140718144012.GA7179@dft-labs.eu> <20140718155959.GN93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140718155959.GN93733@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 19:19:34 -0000 On Fri, Jul 18, 2014 at 06:59:59PM +0300, Konstantin Belousov wrote: > On Fri, Jul 18, 2014 at 04:40:12PM +0200, Mateusz Guzik wrote: > > On Fri, Jul 18, 2014 at 04:06:29PM +0300, Konstantin Belousov wrote: > > > On Fri, Jul 18, 2014 at 01:55:38AM +0200, Mateusz Guzik wrote: > > > > ============================ > > > > GENERAL OVERVIEW OF CURRENT STATE: > > > > > > > > What readers need to do: > > > > - rmb() after reading fp_ops > > > > - check fp_ops for badfileops > > > How can readers see badfileops ? > > > > > > > Not sure what you mean. fp is installed with badfileops, anything > > accessing fdtable before finit finishes will see this. > I referenced falloc_noinstall(). > There must be some miscommunication. If finstall is not executed fp with badfileops (like in kern_openat), readers obviously cannot find this fp. However, if fdalloc is executed (falloc_noinstall + fdalloc which installs fp), readers can find such fp. The latter is the common pattern in the kernel. > > > It seems that all what is needed is conversion of places using > > > falloc() to falloc_noinstall()/finstall(). > > > > > > > This postpones fd allocation to after interested function did all work > > it wanted to do, which means we would need reliable ways of reverting > > all the work in case allocation failed. I'm not so confident we can do > > that for all current consumers and both current and my proposed approach > > don't impose such requirement. > Cleanup should be identical to the actions done on close(2). > > > > > Of course postponing fd allocation where possible is definitely worth > > doing. > Yes, and after that the rest of the cases should be evaluated. > But my gut feeling is that everything would be converted. > So let's say you accept() a connection. With current code, if you got to accept the connection you got it. With your proposal you may find that you can't allocate any fd and have to close fp. This will be visible as accept + close by the other end, while the caller never saw the connection. My guess is people would complain once they encounter such issue. -- Mateusz Guzik