From owner-freebsd-arch@FreeBSD.ORG Sun Aug 24 09:59:07 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89C98A01; Sun, 24 Aug 2014 09:59:07 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 CD86F3BFB; Sun, 24 Aug 2014 09:59:06 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so1324063wiv.9 for ; Sun, 24 Aug 2014 02:59:05 -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=M1QLHpq3PsJ4b4A9C7ZWKPtbYPHBUw901WQSANmGi9U=; b=LTCRTUHEL6oJZrY12wdh5ziSDbiqVp6w07h/WapMhkIHN0jmzg76kaYAapUXC0u4LO qX3lQo6zWXA4/GOIGjPIhoBPrNrCRF4JCtK9XlQGo4xhcbjHFqCj40uMgOgViUmBuwOE xJOwgYMM2p0qPoxB93sdQpbwRTdwqHm9hoNiRrGCji+O8VkhSDmuUwKZ8GILqBsJcWoi pSgIA1eh22nAZFQ7TAXattm6pMQo6RF4uyJKoHU7DlZPaTm2T1OHCHkd75RfFMH9P2LE 70XBjZKeujHUQQUnFaOfhiS1zyOySMWfmU2YBrtxm+54ZIXGyk+HkJzcSn/UfEEOCXof 9zbg== X-Received: by 10.194.222.230 with SMTP id qp6mr15485174wjc.23.1408874345071; Sun, 24 Aug 2014 02:59:05 -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 eb4sm18793882wic.16.2014.08.24.02.59.03 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 24 Aug 2014 02:59:04 -0700 (PDT) Date: Sun, 24 Aug 2014 11:59:01 +0200 From: Mateusz Guzik To: John Baldwin Subject: Re: current fd allocation idiom Message-ID: <20140824095901.GA2045@dft-labs.eu> References: <20140717235538.GA15714@dft-labs.eu> <20140813015627.GC17869@dft-labs.eu> <201408201110.10431.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201408201110.10431.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Benjamin Kaduk , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 09:59:07 -0000 On Wed, Aug 20, 2014 at 11:10:10AM -0400, John Baldwin wrote: > On Friday, August 15, 2014 7:20:03 pm Benjamin Kaduk wrote: > > On Tue, 12 Aug 2014, Mateusz Guzik wrote: > > > > > On Tue, Aug 12, 2014 at 09:31:15PM -0400, Benjamin Kaduk wrote: > > > > On Tue, Aug 12, 2014 at 7:36 PM, Mateusz Guzik > wrote: > > > > > > > > > I would expect soabort to result in a timeout/reset as opposed to > regular > > > > > connection close. > > > > > > > > > > Comments around soabort suggest it should not be used as a replacement > > > > > for close, but maybe this is largely because of what the other end > will > > > > > see. That will need to be investigated. > > > > > > > > > > > > > > I added some text regarding soabort to socket.9 in r266962 -- does that > > > > help clarify the situation? > > > > > > > > > > Nope. :-) > > > > > > It is unclear if the only motivation here is making sure nobody else > > > sees the socket when given thread calls soabort. This would be easily > > > guaranteed in here: fd allocation failed, fp with given socket was never > > > exposed to anyone. > > > > > > So, if you say soabort would work here just fine, I'm happy to use it > > > and blame you for problems. :-) > > > > Hmm, I was hoping that jhb would chime in and save me from being on the > > hook, but it does look like soabort() would be acceptable in this case. > > I think having the EMFILE/ENFILE case use the same exact logic as a listen > queue overflow (i.e. soabort()) is correct. > So I was playing with converting stuff and I think I hit the wall with procdesc. procdesc is instantianed after fork cannot fail anymore. I'm not so sure we can finish up procdesc for a process which didn't fork yet, and I seriously doubt we can just kill the new process to revert stuff (e.g. what about SIGCHLD or kqueue events which fire). That said, like previously proposed plan would be: where applicable: 1. allocate fp 2. do stuff 3. install fp under free fd in cases like procdesc: 1. reserve fd 2. allocate fp 3. do stuff 4. install fp This introduces a special case to dup2 when newfd is reserved. Linux fails in this case with, so I believe we can get away with it as well. When it comes to avoiding taking filedesc lock multiple times for succeedeing case, we can get away with the following: 1. finit(..); 2. ensure all writes are completed 3. fdp->fd_ofiles[fd].fde_file = fp; -- Mateusz Guzik