From owner-freebsd-arch@FreeBSD.ORG Fri Jun 20 02:16:27 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 51C31673; Fri, 20 Jun 2014 02:16:27 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (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 6585624D3; Fri, 20 Jun 2014 02:16:26 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id t60so3117385wes.18 for ; Thu, 19 Jun 2014 19:16:24 -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=mVPi5W03PviADKx5rapdjPxjDelFdBbDo62lt/OxF3c=; b=IY/WvByqgTS2rFshOHegoBEj1D4v51dMGlJM8lXJ3dMHzw/LsKiVk2KFA/oEONppLK wPaI+40Mfxcv6fQi+mPkUcW+dF4lF8/WQwBN17a+CBhZzu3gct6K/o0U9EUCat3BBjEh Kej1iljrTL72Y4ULnONn3uaxthTpSxB2zhofKxFkcJ/yOUPNOZkZ9YGa8JY7CPrfx6zp YSjbvrYOR0CDj3m6lihryD0+8RhegY1OJh6YoponQnPf7py9u/AF303x6szbBgSoLVRf KstXCbvLimgGEfTI8E5idx3zSfJ1kc5/3AZ2Gj/WbWgZ9VRlecdSeZg9mJYnP3szpeP8 YDFg== X-Received: by 10.180.75.71 with SMTP id a7mr393471wiw.27.1403230584646; Thu, 19 Jun 2014 19:16:24 -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 gp6sm276021wib.12.2014.06.19.19.16.23 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 19 Jun 2014 19:16:23 -0700 (PDT) Date: Fri, 20 Jun 2014 04:16:21 +0200 From: Mateusz Guzik To: Adrian Chadd Subject: Re: capability races (was: Re: Seeing ENOTCAPABLE from write FDs in kqueue?) Message-ID: <20140620021621.GC5830@dft-labs.eu> References: <20140608220000.GA5030@dft-labs.eu> <20140608230059.GB5030@dft-labs.eu> <20140618203314.GB7157@dft-labs.eu> <20140620010424.GA5830@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Robert Watson , "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, 20 Jun 2014 02:16:27 -0000 On Thu, Jun 19, 2014 at 07:05:48PM -0700, Adrian Chadd wrote: > [snip] > > I'm increasingly wary of hand-rolled memory barrier / atomic using > constructs like this. It's way, way too easy to shoot a foot off on an > architecture that you don't have or know. > Sure, hence I'm lookin for someone with strong memory-barrier-fu. > So, if we're going down this rabbit hole further, I think we should > first define all the places this stuff gets touched and try to come up > with some behavioral description that we could try and link to some > existing (non-patent-encumbered) no-lock based design pattern. > > So in your example, yes the pointer assignment is atomic, but there's > no current guarantee that anything currently operating on that pointer > has finished. That's what things like RCU address. > But we don't need that guarantee in here. File tables are freed only on process exit specifically because we never know if all threads finished reading. File table pointer is refreshed and fp validated before is returned to the caller; if validation fails there is relookup. Having RCU-like solution would allow us to free old tables without the process exiting of course, but would not affect correctness. As a side note, we could easily free old tables in singlethreaded processes. Multithreaded would require actual work to make sure all threads are stopped. -- Mateusz Guzik